Conditions and branching

A condition routes the flow. Where an action does something, a condition decides what happens next: it looks at the data passing through it, answers a yes-or-no question about it, and sends the run down one of two paths.

Add one by clicking + on an edge and selecting Condition.

True and false

Every condition has exactly two outputs, a true handle and a false handle. Connect a different branch of nodes to each. What arrives at the condition is unchanged by it—a condition never modifies the data, it only chooses a direction—so both branches start from exactly the same values.

The two branches are not obliged to be symmetrical. A condition with nothing wired to its false handle simply ends the run down that side; the run is not a failure, it just stops there. That is the usual shape for a guard: continue if the data is interesting, quietly do nothing if it is not.

What happens to the branch not taken

Once a condition routes, everything hanging off the other handle is marked skipped. Skipped is not a failure and not a success—it is the record that this step was never reached, and it is what the run history shows for the whole untaken side.

Skipping cascades. A step is skipped when nothing routed to it, so the step immediately after the untaken handle skips, and then the step after that, and so on down the branch. You do not have to do anything to make a branch stop; it stops because nothing ever arrives.

The cascade ends where the branches meet again. A step needs only one predecessor to route to it in order to run, so a step both branches feed into runs whichever way the condition went. That is how you rejoin: wire both branches to the same downstream step, and the flow continues with one common tail.

Two consequences are worth knowing:

• A step on a skipped branch produces no output. A downstream step that references it gets nothing, so avoid reading across from one branch into the other—in any given run, only one of them happened.
• Nesting works the way you would expect. A condition on a skipped branch is itself skipped, and takes both of its own branches with it.

Chaining conditions

There is nothing special about placing a condition after another condition; the second one simply evaluates on the branch that reached it. Two conditions in a row give you three outcomes, three give you four, and so on. This is often clearer than packing every clause into one expression, because the run history then shows which decision the flow actually turned on rather than only that a single large expression came out false.

The condition types

Every condition ships with the product—no integration adds one of its own. They differ in how they arrive at their yes or no: some evaluate an expression you build, some run code, some ask an AI agent, and one just splits traffic by percentage.

For each of them, and every field it takes, see Conditions in the built-in node catalog.

Building an expression

Expression-based routing is the most common kind, so it is worth understanding the shape it is built from: a tree of comparisons, where the leaves compare values and the branches combine them.

Comparisons test one or two values, each of which can be a variable or a literal:

• Two-value operators: Equals (==), Not Equals (!=), Greater Than (>), Less Than (<), Greater Or Equal (>=), Less Or Equal (<=), Contains, and Matches Regex.
• One-value operators: Is Empty, Is Not Empty, Is Truthy, and Is Not Truthy.

Combinators group comparisons:

• All Of—true only when every condition inside it is true.
• Any Of—true when any condition inside it is true.
• Not—inverts the condition inside it.

Because All Of, Any Of, and Not can contain other comparisons and combinators, you can express logic of any depth—for example, "status equals published And (section equals news Or section equals sports)." The editor shows a readable preview of the expression as you build it.

The same expression builder appears elsewhere. A trigger's fire condition is built exactly this way, so learning it once covers both.