The Menu Node
Asks a question, offers up to ten answers, and holds the run open until the visitor picks one. A Message node sends and carries on; a Menu node waits, so the reply arrives inside the run rather than afterwards as a fresh visitor message.
Write the Question and the Options#
| Field | What it does | Limit |
|---|---|---|
| Question | The sentence above the options, on every channel | None |
| Menu title | On the web, the heading above the options. On WhatsApp, the button that opens the menu, where the menu sits behind one. Left blank, WhatsApp's button reads "Choose" and the web draws no heading | 20 characters |
| Option label | What the visitor taps, and what the port is named on the canvas | 24 characters |
| Description | An optional line under the label. Never sent back, so it is free to explain | 72 characters |
| Value | What .value holds for the nodes that follow. Left blank, the label is used | None |
Every field accepts {{variables}}, so a menu can be built from something an API Request returned rather than fixed when the workflow was written. Ten options is the cap, and the editor replaces the add button with the reason when you reach it.
Set a Value to Keep the Label Rewritable#
The label is what a person reads, and Value is what .value holds for the nodes that follow. Keeping them apart means the wording can change without anything downstream breaking: set the value to valuation and the label can go from "Book a valuation" to "Arrange a free visit" between one release and the next, while every Decision node reading .value carries on matching. A visitor picking an option always sends its label, so a value you choose is for your own workflow to read rather than for matching the reply.
Ports need no such help. A port is keyed to a hidden id minted when the option is added, so renaming an option moves no wires. Deleting an option is the one thing that removes a port, and the canvas drops its wire with it.
Branch on the Answer, or Keep One Next Port#
Branch on the answer is a toggle and it is on by default. On, the node draws one port per option in the order they are listed, then Anything else last.
Anything else is taken whenever the reply is not one of the options: a typed question, a photo, or a conversation going somewhere the menu did not offer. Nothing is guessed, so a reply of "yeah" does not resolve to an option called "Yes". Connect that port to something useful, because it is where every visitor who wanted something you did not offer ends up.
Switch the toggle off when the options all lead to the same next step. The node keeps one Next port, still asks, still waits, and still writes .label and .value; only the routing changes, so a workflow can be switched either way without anything downstream being re-pointed. There is no Anything else port with branching off, so a visitor who typed something of their own leaves by Next with .value empty, which is how a later Decision node tells the two apart.
Read Which Option They Picked#
The answer is the branch, so most workflows read nothing at all. Where a later node needs the answer as text, both halves are stored under the node's label: .label holds the option's label, or the visitor's own words on the Anything else branch, and .value holds the option's value, or nothing when no option matched.
A node labelled What they need writes {{What_they_need.label}} and {{What_they_need.value}}, and the variable picker of every node downstream offers both.
What Each Channel Draws#
One authored menu, three renderings. The editor tells you which one applies as you type, under How this arrives.
| The menu you wrote | On WhatsApp | On the web and Instagram |
|---|---|---|
| Three or fewer options, no descriptions | Reply buttons, with nothing to open first | The full list on the web, a numbered list on Instagram |
| Four to ten options, or any description | A menu behind one button | The full list on the web, a numbered list on Instagram |
Reply buttons have no room for a description, so a single description anywhere turns the whole set into a menu rather than dropping what you wrote. Instagram always writes the options into the message as a numbered list, because an interactive payload renders as an empty bubble on Instagram Lite and takes the message text with it. See what differs per channel.
Whichever rendering a visitor gets, the answer reaches this node the same way, and replying with either the number or the option text matches.
Write Options That Read as Options in Prose#
They arrive as a numbered list on Instagram, so "tap the button below" is wrong there. Put the difference between two options in the description: "Get a quote" and "Book a valuation" look interchangeable until one of them says "sent by email within a day".
Common Questions#
How Do I Read Which Option They Picked?#
Follow the port. Each option is its own connection, so the branch itself is the answer. Where a later node needs the answer as text, read .label or .value.
Can I Use a Decision Node Instead of the Ports?#
Yes, and that is what switching branching off is for. Give the node its single Next port, put a Decision node after it, and compare .value. Six options leading to two outcomes reads better as one comparison than as six wires crossing the canvas.
What Happens If the Visitor Types Something Else?#
With branching on, the run leaves by Anything else with what they said in .label. With it off, it leaves by Next and .value is empty. Nothing is matched approximately either way.
Can I Group the Options Under Headings?#
No. Every option is a row of the same kind on every channel, and the description line is where the difference between two of them goes.
Can a Menu Be the First Thing a Visitor Sees?#
It can, though conversation starters are the better fit for an opening move. They are configured in bot settings and reach every channel. A menu is for a point in a conversation where the choices are known.
Does the Menu Repeat If They Ignore It?#
No. A visitor who says something unrelated leaves by Anything else and the run continues from there. To ask again, connect that port back to this node.