Question
Category: Input
Overview
The Question node sends a prompt to the customer and pauses the flow until a reply is received. The reply is captured into a variable that downstream Condition, Set Variable, API, or Agent nodes can read. The node supports two capture modes — free text (open-ended) and buttons (constrained choice) — picked from a toggle in the drawer.
When to use
- Collect free-text answers (full name, address, complaint description).
- Capture an unstructured reference (policy number, ticket id) before validating it server-side.
- Ask a short constrained question with up to a handful of button replies, without reaching for the dedicated Button node.
- Ask follow-up questions inside a longer interview-style flow.
Ports
| Port | Direction | Description |
|---|---|---|
in | input | Receives the flow from the previous node. |
next | output | Fires after a valid free-text reply is captured and written to the target variable. (Free-text mode.) |
<button_key> | output | One port per configured button, in buttons mode. The matching button fires when the customer taps it (on WhatsApp the tap is matched automatically) or types its label. |
fallback | output | Fires when the reply fails to coerce to the declared variable type (e.g. “twenty” for a number) or when no button label matches. |
talk_to_agent | output | Only present when the “Talk to agent” escape-hatch toggle is on. Fires when the customer asks to speak to a human while the question is active. |
Configuration
Prompt (EN / AR)
The question shown to the customer. Bilingual fields work the same way as in the Message node.
Capture mode
Toggle between Free text and Buttons. Free text accepts any reply and coerces it to the declared variable type. Buttons only accepts a choice from one of the configured buttons.
In buttons mode on WhatsApp, the node now sends native, tappable reply buttons — the customer taps instead of typing, and the tap is matched to the right branch automatically. The native render applies with three or fewer buttons; labels are truncated to 20 characters per language. With more than three buttons, WhatsApp can’t show native buttons, so the bot falls back to a plain text message and the customer types their choice (for more than three options, use the List node instead).
Capture to variable
Three fields, side by side:
- Scope —
recipe(lives only inside this recipe’s session),conversation(default — survives across recipes within the same chat) oruser(persists on the contact across conversations). - Type —
string,number,boolean, ordate. Free-text replies that can’t be coerced to the chosen type fall through thefallbackport. - Variable name — referenced downstream as
{{variable_name}}. Use snake_case for consistency.
Buttons (only in buttons mode)
A repeater row per button: a stable internal key (which becomes the output port name) plus the visible English and Arabic labels. Each button gets its own labelled output port on the node.
Allow user to talk to agent
When enabled, the node exposes an extra talk_to_agent port. If the customer asks to speak to a human while the question is open, the flow exits through that port instead of fallback.
Hide the typing input while this question is active
Hides the agent-side typing box on the conversation while the question is awaiting a reply. Useful for kiosk-style flows where any free typing would noise up the transcript.
Send the tenant-default nudge if no reply
Enables the tenant’s default unanswered-question nudge (configured in Settings → Inbox → Nudge Rules) for this specific question.
Data classification
Tags the captured value with a sensitivity class (Public / Sensitive / Internal / PHI). PHI values are automatically tokenized when they flow through Agent or Smart Plug calls.
Purpose tag
Shown when classification is anything other than Internal. A short label describing why the value is being collected (e.g. claim_intake, appointment_booking) — surfaced in audit reports.
Common patterns
Capture → Validate → Branch
Question (saves to “policy_number”) → API (lookup) → Condition on the API result.
Retry on bad input
Wire the Fallback port back through a Message (“Sorry, I didn’t catch that”) and another Question, then loop a maximum of 2–3 times before transferring.
Limits & validation
- The captured variable scope defaults to
conversation. Pickuserif you want the value to survive into the next conversation with the same contact. - In buttons mode on WhatsApp, three or fewer buttons render as native tappable reply buttons (tap matched to its branch automatically); button labels are truncated to 20 characters per language.
- WhatsApp caps native reply buttons at three per send. With more than three buttons the message falls back to plain text and the customer types their choice — reach for the List node instead of buttons mode here.
Troubleshooting
The flow keeps re-asking the question.
Check the next-node logic — if you wired the fallback port back into the prompt, every coercion failure or unmatched button will replay the question. Add a retry counter via Set Variable, or wire fallback to a Transfer after N attempts.
Customer reply not visible to downstream nodes.
Verify the variable name in Capture to variable is filled in and that downstream references use the exact same name and scope.
Free-text reply always falls through fallback.
Almost always a type-coercion miss — e.g. the variable type is number but the customer typed “twenty”. Either keep the type as string and validate in a later Condition node, or use a Typed Input node (which has built-in formats for email, phone, date, etc.).
See also
Use the dedicated Button or List node when you only need a choice (no need to capture free-text input). Use Typed Input when you need stricter format validation than the four built-in types here (e.g. email, phone, regex patterns).