Branching is what makes Conversational Flow powerful. Instead of a linear script, your agent can take different paths based on what callers say, how they respond, or data from your systems.
How Branching Works
Agent Asks
The current node poses a question or presents options.
Caller Responds
The caller says something (or doesn’t respond).
Conditions Evaluated
The AI checks each branch condition against the response.
Path Selected
The matching condition determines which node comes next.
Configuring Branches Click any Default node, then click Branching to configure output paths.
Adding a Branch
Click the Default node you want to branch from
Click Branching in the configuration panel
Click + Add Branch
Configure the condition
Connect to the target node
Branch Fields Field Description Label Name shown on the canvas (e.g., “Wants Billing Help”) Condition What triggers this path (natural language or variable-based) Target Node Where the conversation goes when this condition matches
Condition Types Natural Language
Variable-Based
Compound (AND/OR)
Default/Fallback
Write conditions in plain English. The AI interprets caller intent. Examples: Condition Matches When Caller Says ”User confirms" "Yes”, “Yeah”, “That’s right”, “Correct" "User declines" "No”, “Nope”, “Not really”, “I don’t think so" "User asks about billing" "I have a billing question”, “About my invoice" "User wants to speak to a person" "Can I talk to someone?”, “Get me a human" "User is frustrated” Angry tone, complaints, escalation requests ”Anything else” Fallback — catches everything not matched above
Write conditions as if describing the caller’s intent, not their exact words. The AI handles variations automatically.
Route based on variable values from APIs or collected data. Syntax: {{variable_name}} operator value
Operators: Operator Meaning ==Equals !=Not equals >Greater than <Less than >=Greater or equal <=Less or equal
Examples: Condition Logic {{budget}} > 10000High-value lead path {{account_tier}} == "premium"VIP treatment {{attempts}} >= 3Escalation after 3 tries {{api.balance}} < 0Negative balance handling
Combine multiple conditions for complex routing. AND Conditions: {{account_tier}} == "premium" && {{budget}} > 10000
Both must be true. OR Conditions: {{issue_type}} == "billing" || {{issue_type}} == "payment"
Either can be true. Catch-all for when no other condition matches. Use “Anything else” or leave condition empty for fallback behavior. Always include a default branch. It handles:
Unexpected responses
Unclear answers
Edge cases you didn’t anticipate
Silence or no response
Good fallback prompt: I didn't quite catch that. Could you tell me again — are you calling about billing or technical support?
Branch Order Matters Conditions are evaluated top to bottom. The first matching condition wins.
Put specific conditions first, fallback last. If “Anything else” is first, it will always match and other conditions will never trigger.
Correct Order:
{{budget}} >= 50000 → Enterprise Path{{budget}} >= 10000 → Professional Path{{budget}} >= 1000 → Starter PathAnything else → Self-Serve Resources
Incorrect Order:
{{budget}} >= 1000 ← This catches everything above $1k{{budget}} >= 10000 ← Never reached{{budget}} >= 50000 ← Never reached
Real-World Examples Support Routing [Ask Issue Type] "I'm here to help! Are you calling about billing, technical support, or something else?" Branches: ├── "User asks about billing" → [Billing Flow] ├── "User has technical issue" → [Technical Flow] ├── "User wants to speak to someone" → [Transfer Call] └── "Anything else" → [Clarify and Re-ask]
Lead Qualification [Ask Budget] "What's your approximate budget for this project?" → Store response as {{budget}} Branches: ├── {{budget}} >= 50000 → [Enterprise Path] ├── {{budget}} >= 10000 → [Professional Path] ├── {{budget}} >= 1000 → [Starter Path] └── "Anything else" → [Self-Serve Resources]
Confirmation Flow [Confirm Appointment] "Just to confirm — you'd like to book for Tuesday at 3pm. Is that correct?" Branches: ├── "User confirms" → [Complete Booking] ├── "User wants to change" → [Modify Appointment] └── "Anything else" → [Re-confirm]
API Response Routing [API Call: Check Account Status] Branches: ├── {{account_status}} == "active" → [Standard Service] ├── {{account_status}} == "suspended" → [Reactivation Flow] ├── {{account_status}} == "premium" → [VIP Service] └── API Error → [Fallback / Transfer]
Best Practices
Always include a fallback
No matter how many conditions you define, something unexpected will happen. Your fallback should:
Acknowledge the response
Re-ask the question differently
Offer options to clarify
"I want to make sure I understand. Are you calling about billing, technical issues, or something else entirely?"
Keep conditions mutually exclusive
Avoid overlapping conditions that could both match. Overlapping (Bad) Exclusive (Good) “support” AND “technical support" "billing” OR “technical” OR “other” >10 AND >5010-50 AND >50
When conditions overlap, the first one wins — which may not be what you want.
It’s easy to forget a branch while testing. Be systematic:
List all possible paths
Test each one deliberately
Try edge cases (silence, gibberish, topic changes)
Review in Conversation Logs
Too many nested branches become impossible to manage. If your flow is getting too deep:
Can you combine some branches?
Should some paths be separate flows?
Is Single Prompt better for this use case?
Labels appear on the canvas — make them meaningful. Bad Labels Good Labels ”Option 1" "Wants Billing Help" "Path A" "Budget > $10k" "Yes" "Confirmed Appointment" "Branch 2" "Frustrated Customer”
Complex Patterns Loop Back (Retry) For scenarios where you need to re-ask:
[Ask Budget] ↓ [Validate Response] ├── Valid → Continue to next step └── Invalid → Loop back to [Ask Budget]
Avoid infinite loops. Add a counter variable and exit after N attempts. After 2-3 retries, offer to transfer or end gracefully.
Parallel Paths That Merge Different paths can lead to the same destination:
[Qualify Lead] ├── High Budget → [Fast Track] ─────────┐ └── Standard Budget → [Standard Process] ├→ [Schedule Demo] │
Guard Rails Add safety branches for edge cases:
[Any Node] ├── Normal flow conditions... ├── "User seems upset or frustrated" → [Empathy Response] ├── "User mentions legal or lawsuit" → [Transfer to Manager] └── "Anything else" → [Standard Fallback]
Debugging Branches When branches don’t work as expected:
Check Conversation Logs
See exactly which conditions were evaluated and which matched.
Verify Condition Syntax
Typos in variable names or operators fail silently.
Test the Fallback
If fallback triggers too often, your conditions may be too specific.
Review Branch Order
Conditions are checked top to bottom — earlier matches win.
Next 
