Condition Node

The Condition node evaluates one or more rules against session variables and routes execution to different branches based on the results. It is the primary node for adding decision logic to your flows.

When to Use

• You need to branch the conversation based on user input, API responses, or session data.
• You want to check whether a variable matches a specific value (e.g., account tier, language, intent).
• You need to validate data before proceeding (e.g., check if an API call returned results).

Configuration

Rules

Each condition rule defines a comparison:

Property	Description
Field	The variable name to evaluate (e.g., user_tier, order_details.status)
Operator	The comparison operator (see table below)
Value	The value to compare against. Supports {{variable}} interpolation.
Target	The output handle to follow if this rule matches

Operators

Operator	Description	Example
eq	Equals	user_tier eq "premium"
neq	Not equals	status neq "closed"
gt	Greater than	order_total gt 100
gte	Greater than or equal	retry_count gte 3
lt	Less than	score lt 0.5
lte	Less than or equal	attempts lte 5
contains	String contains substring	user_message contains "cancel"
regex	Matches a regular expression	email regex "^[^@]+@[^@]+$"
is_empty	Variable is empty, null, or undefined	user_name is_empty
is_not_empty	Variable has a value	api_response is_not_empty

Output Handles

The Condition node has dynamic output handles:

• One handle per rule, labeled with the rule's target name (e.g., "Premium", "Standard").
• A Default handle that fires when no rules match.

Each rule is evaluated in order from top to bottom. The first rule that matches determines which output handle is followed. If no rules match, execution follows the Default handle.

TIP

Order your rules from most specific to least specific. The first matching rule wins, so place edge cases and high-priority checks at the top.

imageCondition node config panel showing a list of rules with field, operator, value, and target columns, plus an Add Rule button and a Default route label field

Condition rules configuration panel

imageCondition node on the flow builder canvas showing multiple labeled output handles on the right side, one per rule plus a Default handle, each connected to different downstream nodes

Condition node with multiple output handles on the canvas

Multiple Conditions

You can add as many rules as you need. Common patterns include:

Two-Way Branch (If/Else)

One rule with a Default fallback:

Rule 1: user_tier eq "premium"  --> "Premium Path"
Default                          --> "Standard Path"

Multi-Way Branch (Switch)

Multiple rules, each routing to a different branch:

Rule 1: intent eq "billing"     --> "Billing Flow"
Rule 2: intent eq "support"     --> "Support Flow"
Rule 3: intent eq "sales"       --> "Sales Flow"
Default                          --> "General Flow"

Validation Check

Check if required data exists before proceeding:

Rule 1: account_number is_not_empty  --> "Lookup Account"
Default                               --> "Ask for Account Number"

Combining with Other Nodes

A common pattern is to use a Condition node after an API Call to branch based on the response:

[API Call: Get Order] --> [Condition: order_status]
                            ├── "shipped"  --> [Message: "Your order has shipped!"]
                            ├── "processing" --> [Message: "Your order is being prepared."]
                            └── Default --> [Message: "Order status: {{order_status}}"]

WARNING

If you add rules but do not connect their output handles to any node, the flow will end silently when that rule matches. Always connect every output handle, or use a Message node on dead ends to inform the user.

Handles

Handle	Direction	Description
Input	In	Receives execution from the previous node
Rule handles	Out	One per rule -- routes to the matching branch
Default	Out	Fires when no rules match