Use Case 2: Branching by customer choice

Level: basic · Modules: Scenario Builder · Nodes: MessageKeyboard

Before you start: read Edge-driven flow and Branching: edges / Router / switch.

Required permissions and access

What you need	Where in the menu	Why
Scenario Builder	Menu → Scenario Builder	Menu and edges

If a section is missing from the menu — check your account permissions or contact ConnectiveOne support.

Business context

The bot shows a menu: “Sales”, “Support”, “Other” — and routes the customer into different scenario branches. This is the foundation of most client bots: one entry, several business directions.

Expected result

Menu buttons lead to different branches of the scenario.
The choice value is stored in the user_choice variable (for Runs and later steps).
If the customer typed text instead of tapping a button — a clear hint (default).
Understanding: for button menus the primary approach is separate edges, not Router.

Flow architecture

Start → MessageKeyboard (3 buttons)
   ├─ edge "sales"    → MessageKeyboard (Sales branch)
   ├─ edge "support"  → MessageKeyboard (Support branch)
   ├─ edge "other"    → MessageKeyboard (Other branch)
   └─ edge default / free text → “Choose a menu item”

Important: for button menus — a separate edge for each MessageKeyboard button + default for free text. The Router node does not fit here: it works with request-context fields (channel, status, tags…), not with an arbitrary scenario variable such as user_choice.

Step-by-step implementation

Node: Message with buttons.

Parameter	Value	Why
Text	“Choose a topic:”	Menu
Keyboard type	inline	Buttons under the message
Button 1	Text: “Sales” · payload / value: `sales`	Stable value
Button 2	“Support” · `support`
Button 3	“Other” · `other`
Output Variable	`user_choice`	Saves the choice — check in Runs

Edges:

Edge	Where	Why
`sales`	MessageKeyboard “You chose Sales…”	Separate branch by button edge
`support`	“Support…”
`other`	“Other…”
Default	“Tap one of the menu buttons.”	Do not leave the customer without a reply

Step 2. Three reply branches

Node: MessageKeyboard (×3).

Branch	Text (example)
sales	“Sales team. Write what you’re interested in.”
support	“Support. Describe the problem.”
other	“General questions. How can we help?”

Step 3. Check in Runs

Each button → its own branch.
In the trace: user_choice = sales | support | other.
Random text → default.

When you need branching by a variable (later)

For this Use Case, edges are enough. If after an API call, categorizer, or another step you need to branch on a saved scenario constant — use Action switch (not Router). Details and common pitfalls: Built-in actions — switch.

Legacy action if_else in older bots also evaluates expressions and has an else branch. For new flows by a variable — switch; for request context (channel, status, tags) — Router.

Acceptance criteria (self-check Runs)

Each of the three buttons leads to a separate branch.
In the trace, user_choice matches the tapped button.
Free text (not a button) → default edge, customer sees a hint.
Default edge is connected — no “silence” after arbitrary input.

Common mistakes

Symptom	Cause	What to do
All buttons lead to one branch	One edge for all buttons	Separate edge per payload
`user_choice` empty	Output Variable not set	Enable Output Variable on MessageKeyboard
Bot “goes silent” after text	No default edge	Connect default → hint
Cannot pick `user_choice` in Router	Router does not accept arbitrary scenario variables	Keep menu branching on edges; for a constant use `switch`