WhatsApp Question

Every node so far finishes what it is doing and hands on. This one sends a message and then stops — the execution ends, its state is written down, and nothing is running. When the customer replies, days later if that is when they get round to it, the workflow starts again from exactly this node with their answer in hand.

That is the whole idea, and it is what separates a WhatsApp broadcast from a WhatsApp conversation. Chain a few of these and you have an intake form that lives in someone's messages: what are you interested in, when suits you, what is your budget — each answer stored under a name, each one available to everything downstream.

Name the variable. variable_name defaults to user_response, which is fine for one question and useless for four — every node would be writing to the same name. Rename each one for what it holds and the rest of the workflow reads like prose.

The buttons array is the interesting field. Each entry has a label the customer sees and a payload that identifies it — and that payload becomes an output handle on the node. Tap “Machine Learning” and the workflow does not merely record the words; it leaves down the ML edge.

The truncation is the node's, not Meta's. It is easy to assume WhatsApp is trimming your list somewhere out of sight. It is not — the node itself cuts to ten before sending, and the routing graph is cut to ten to match, so the two stay consistent. The practical rule: if you have more than ten choices, this is the wrong shape. Ask a narrowing question first.

The default path matters more than it looks. Someone who ignores your three buttons and types “can I speak to a person” goes down it. Wire it. A flow with three branches and nothing on default silently drops every customer who did not do as they were told.

There is one more thing that is not in any list of outputs and is worth knowing, because it looks like magic when you meet it: the node also files the reply under message, message_text, user_input and query. Those are the names a Core Agent, an LLM node or a Knowledge Base search look for by default — so putting one of those directly after this node works without wiring anything. Convenient, and worth remembering when a node downstream mysteriously already knows the answer.

The pause is bounded. timeout_minutes defaults to 60 and caps at 1440 — a day. When it expires the node sends timeout_message and the workflow carries on down its default path, so a customer who wandered off gets a polite close rather than nothing.

The 24-hour window applies to the question too. This node sends a free-form message, so everything from the last lesson holds: if the customer has not messaged you in 24 hours, the question does not go out. A multi-step flow is therefore safe while they are actively replying and stops dead the moment they leave it overnight — which is exactly when your timeout was going to save you and cannot, because the question was never asked.

An empty payload is not the same as no payload. The handle id falls back through payload, then the label, then a generated name. Give every option an explicit short payload — ml, ai, da — and your edges stay stable when somebody rewords a label. Leave payloads blank and renaming “Machine Learning” to “ML & AI” silently moves the branch.

Expected type does not validate for free. Setting expected_type to number constrains what counts as an answer, which means a customer who types “about five thousand” has not answered. That is correct behaviour and it is also how a flow gets stuck arguing with someone. Use any and check the value yourself downstream unless you genuinely need the shape.