The Branch Node routes your conversation flow based on conditions. It evaluates variables, user responses, or action results and directs the flow to different paths—keeping your logic clean, modular, and easy to debug.

The Branch Node:
Important: Branch Nodes are invisible to users. They evaluate conditions and immediately route to the next node. If you need to collect information, use a Conversation node instead.
In Flow Designer, click the Plus icon and select Branch
For each outgoing branch, configure:
Branch Name:
Branches are evaluated top to bottom—the first matching condition wins. Order them strategically:
Each branch in your Branch Node needs a condition that determines when that path should be taken. You can choose between two condition types: Deterministic Rule for precise, structured logic, or Prompt for flexible, natural language conditions.
Use Deterministic Rule when you need precise, structured conditions based on variable comparisons.
Configuration:
=), Not equal (!=), Contains, Starts with, Ends with, Less than (<), Greater than (>)true, ["admin","superuser"], 1000)Multiple conditions:
Example:
Use Prompt when you want flexible, natural language conditions that can handle variations in how users express themselves.
When to Go Here:
{variable_name} and action results with <action.field>Example:
The flow engine pauses at the Branch Node after the previous node completes—whether that was a user response in a Conversation Node, a Custom Action in an Instruction Node, or a Function Node updating data.
Immediately, it evaluates each outgoing node’s condition in sequence.
First-Match Wins: The engine checks Node 1’s condition first. If it’s true, the flow goes down Node 1. If not, it checks Node 2, and so on.
You can also select in the Deterministic Rule that All Rules Must Be True, if you want to branch based on multiple conditions/variables.
Fallback Node (“Else” or “Default”): Best practice is to include a final, catch-all node with condition true—this avoids runtime errors if none of your prior conditions match. Label it clearly (e.g., “Default Path”).
Always include a fallback/default branch at the end. This prevents errors and ensures your flow never gets stuck.
Branch Nodes are invisible to end-users. There’s no prompt or pause for a user reply—unless a later node explicitly asks. The Branch Node only does logical evaluation, then immediately hands off to the next node.
Break complex logic into multiple Branch Nodes rather than cramming everything into one:
This is a common mistake that causes flows to get stuck.
For more details, see the Greeting Message documentation.
Reference variables collected from Conversation nodes and action results from Custom Actions:
{variable_name} syntax (e.g., {user_email}, {party_size})<action.field> syntax (e.g., <availability.available>)You can view all available variables in the Variables guide.
If multiple Branch Nodes rely on the same data, make sure that data comes from a single source upstream. Don’t recalculate or redefine variables in multiple places—consolidate to avoid inconsistencies.
If all you need is to wait for user text or a button click, use a Conversation node instead. Branch Nodes should not generate output or wait for user input—they should only evaluate logic and route the flow.
Yes! In Deterministic Rule mode, click “Add Rule” to chain multiple conditions. Toggle “All Rules Must Be True” if you want all conditions to be met (AND logic), or leave it off for OR logic (first matching condition wins).
Yes! Reference action results using <action.field> syntax. For example, <availability.available> or <order.status>.
Deterministic Rule uses precise variable comparisons with operators (equals, greater than, etc.). Prompt uses natural language descriptions. Use Deterministic Rule for precise logic, Prompt for flexible, language-based conditions.
No. The Greeting Message doesn’t collect user input, so a Branch Node placed immediately after it has no data to evaluate. Always use a Conversation node between Greeting and Branch to collect the variable you need.
Branch Nodes do not speak or execute API calls—they only evaluate conditions and route the flow to the correct next node.
Keep conditions simple, ordered, and mutually exclusive wherever possible.
Always include a fallback branch (condition true or else) to avoid “no valid path” runtime errors.
Name your Branch Node clearly so that anyone scanning your flow instantly grasps the decision logic.
If your logic grows complex, break it into multiple Branch Nodes in series rather than stuffing everything into one giant branch.