Condition

Category: Logic

Overview

The Condition node routes the flow based on rules evaluated against stored variables, contact attributes, and runtime context. Each rule produces its own labelled output port, with a default Else port catching everything that matched nothing. Conditions are evaluated top-to-bottom; the first match wins.

When to use

Route by customer attribute (VIP tier, membership status, language).
Branch on a Question or API result (status === “active”, amount > 1000).
Compose multi-rule logic without nesting multiple nodes.

Ports

Port	Direction	Description
`in`	input	Receives the flow from the previous node.
`<branch_key>`	output	One output per branch, named by the branch’s stable key. The first branch whose expression is true fires.
`else`	output	Always rendered, even when you haven’t added any branches. Wire it to a sensible default path — anything that matched nothing exits here.

Configuration

Branches

Ordered list of branches. Each branch row has:

Branch key — a stable internal id that doubles as the output port name (e.g. is_vip, over_threshold).
Admin-facing label — a friendlier display name shown on the node card.
Left side — a {{scope.variable}} reference (e.g. {{conversation.amount}} or {{contact.tier}}).
Operator — picked from ==, !=, >, >=, <, <=, contains, starts_with, is_empty, is_not_empty.
Right side — either a literal value or another {{variable}} reference. Leave blank for the unary operators is_empty / is_not_empty.

Branches are evaluated top to bottom; the first match wins. The else port catches every chat that matched nothing.

Condition node config drawer showing a sample branch row with key, label, left reference, and operator

Common patterns

VIP fast lane

Condition: contact.tier === “vip” → Transfer to priority queue; else → standard flow.

Validation gate

Question (capture amount) → Condition: amount > 1000 → manual review path; else → auto-approve.

Limits & validation

Branches are evaluated top to bottom — order matters. Drag rows to reorder; the first match wins.
== and != coerce numbers and booleans automatically (so "5" == 5 is true), but string-vs-string comparison is case-sensitive. Lower-case both sides via Set Variable upstream if you need a case-insensitive match.
>, >=, <, <= require both sides to coerce to a number — non-numeric values fail the comparison rather than throwing.

Troubleshooting

Always falls through to Else.

Inspect the variable values via the Simulator (left toolbar). Compare the actual runtime value to your rule literal — whitespace and casing are common culprits.

Two rules can both match but only the first fires.

Reorder rules so the most specific condition sits at the top; the first match wins.