Connectors

Conditional Branch Connector

Model IF / ELSEIF / ELSE branching with branch-specific workflow steps — only the first matching branch's steps run.

On this page

What this connector is for Conditional Branch Configuring it Reading the response Example Step Name Step Reference

What this connector is for

Models IF / ELSEIF / ELSE branching directly on the workflow canvas: each branch has its own condition and its own nested steps, evaluated top-to-bottom, with only the first matching branch's steps actually running. Unlike a call-out connector, nothing external happens here — it's purely a structural control-flow point in the workflow, so there's no request/response to configure.

Conditional Branch

Configuring it

Display name (name) — optional, shown on the workflow canvas.
Branches (branches) — one or more IF/ELSEIF branches, each with:
- Label (label) — shown on the canvas (e.g. "IF", "ELSE IF").
- Condition (condition) — a left operand, operator, and right operand. Both operands accept a literal value or a {{...}} expression (step output, {{trigger...}}, or {{runtimeVariables.x}}) — see Step Reference. Supported operators: equals, notEquals, greaterThan, lessThan, greaterThanOrEqual, lessThanOrEqual, contains, notContains, startsWith, endsWith, exists, notExists, isTrue, isFalse, isEmpty, isNotEmpty (the last several ignore the right operand entirely). Conditions can also nest into AND/OR groups rather than a single comparison, built by the condition-tree widget.
- Each nested step inside a branch is itself a normal step — it can be named, referenced by later steps, and configured with its own execution settings.
Includes Else branch (hasFallback) — whether a final, condition-less ELSE branch exists; its steps run only if no earlier branch matched.

Branches are checked in order; the first branch whose condition evaluates true wins — later branches (even ones that would also match) never run. If none match and there's no ELSE branch, the step completes having run nothing at all.

Reading the response

The step's own output (distinct from whatever the matched branch's own steps produced, which remain independently referenceable by their own step references):

{{<stepReference>.response.data.matchedBranchId}} — the id of the branch that matched (or null if none did).
{{<stepReference>.response.data.matchedBranchLabel}} — that branch's label (e.g. "IF", "ELSE").
{{<stepReference>.response.data.branchResult}} — the final result of the last step that ran inside the matched branch (null if no branch matched, or the matched branch had no steps).

A step inside the matched branch is read exactly like any other step, by its own reference — e.g. a branch step named "Apply Discount" (reference applyDiscount) is still {{applyDiscount.response.data.<field>}}, regardless of which branch it lives in.

If a step inside the matched branch fails, the Conditional step itself is marked failed and carries that step's own error message — it doesn't get wrapped in a generic "branch failed" message.

Example

Branches:
  - label: IF
    condition: {{trigger.body.total}} greaterThan 100
    steps: [Apply Free Shipping]
Includes Else branch: true
  - (ELSE) steps: [Charge Standard Shipping]

Cross-reference: a branch commonly contains a For Loop or ends with a Break Loop when it's used to conditionally exit a loop early.

Also applies here

Step Name

What it's for

Every step in a workflow gets a name — either one you set or a default based on the connector and action (e.g. "Get Order Details", "Send Welcome Email"). It's shown throughout the UI and in your execution history, and it's also the source for the step's Reference — a camelCase identifier auto-generated from the name (e.g. "Get Order Details" → getOrderDetails) — which is what you actually use in {{...}} expressions to read this step's output from later steps. See Step Reference.

Rules

Must be at least 2 characters, and 50 characters or fewer.
Must be unique within the workflow — reusing a name that's already taken will be rejected, with a suggested alternative (e.g. "Get Order Details 2").
Can't be empty.

Tips

Prefer a descriptive, human-readable name over a generic one — "Get Order Details" is easier to work with later than "HTTP Request 2", especially once a workflow has a dozen steps.
Renaming a step updates every reference to it elsewhere in the workflow automatically.

Step Reference

Syntax

Any input field can reference earlier data using {{expression}}. The expression is evaluated as JSONata — so simple dot-paths and more advanced queries (filters, functions) both work.

Referencing a step's output

Use the step's Reference — a camelCase identifier auto-generated from its Name (e.g. "Get Order Details" → getOrderDetails), shown read-only wherever the step's fields are configured — followed by the field path. Elsewhere in these docs this general pattern is written as {{<stepReference>.field.path}}:

{{getOrderDetails.response.data.id}}
{{getOrderDetails.response.status}}

The raw display name won't work here even though it's what you see in the UI — {{Get Order Details.response.data.id}} isn't valid, since a bare name containing spaces isn't a single JSONata identifier. Always use the camelCase Reference.

You can also reference steps by position instead of by reference:

{{steps[0].response.data.id}}

Referencing trigger data

{{trigger.headers.authorization}}
{{trigger.body.customerId}}
{{trigger.query.page}}
{{trigger.params.orderId}}
{{trigger.method}}
{{trigger.path}}

Referencing workflow variables

{{variables.myVariable}}

See Variables for the full list of variable types and more examples, including connection-type variables.

Referencing runtime variables

A separate, mutable namespace written by the Variable connector while a run is in progress — not the same as the workflow-level variables above:

{{runtimeVariables.myVariable}}

Notes

If an expression can't be resolved (a typo in a step name, a field that doesn't exist), it resolves to an empty string rather than failing the workflow — check your execution history if a value comes through blank.
Object values are automatically JSON-stringified when interpolated into a string field.