Connectors

Parallel Execution Connector

Run every step nested inside it concurrently and wait for all to complete — a fixed fan-out, not an array iteration.

On this page

What this connector is for Parallel Execution Configuring it Reading the response Example Step Name Step Reference

What this connector is for

Runs every step nested directly inside it concurrently, and waits for all of them to finish before the workflow continues. Use it when several steps don't depend on each other's output — e.g. looking up inventory and pricing from two different systems at once — to cut total latency versus running them one after another. It's a fan-out over a fixed set of steps, not over an array; for repeating steps once per array item, see For Loop instead.

Parallel Execution

Configuring it

Name (name) — optional, shown on the workflow canvas. There's nothing else to configure — every step you nest directly inside this block runs in parallel automatically; there's no per-branch toggle to opt a step out.

Each nested step keeps its own name, reference, and execution settings (including its own Continue On Error — see Execution Settings), and is referenced exactly like a normal step afterward, regardless of having run inside a Parallel block.

Reading the response

{{<stepReference>.response.data.stepCount}} — how many steps were run in parallel.
{{<stepReference>.response.data.message}} — a short summary string (e.g. "Executed 2 step(s) in parallel").
{{<stepReference>.error.failures}} — present (as a top-level field, not nested under response) only when at least one branch step failed with Continue On Error enabled on that step: an array of {stepId, stepName, reference, error} for each one.

The actual data you want almost always comes from the individual branch steps, not this summary — a branch step named "Get Inventory" (reference getInventory) is read exactly like any other step: {{getInventory.response.data.<field>}}.

If a branch step fails without Continue On Error enabled, the whole Parallel step fails outright (its other, still-running branches' results are discarded rather than partially reported) — enable Continue On Error on any branch step whose failure shouldn't take down the rest.

Example

Parallel Execution: "Fetch inventory and pricing"
  ├─ Get Inventory   (HTTP Connector)
  └─ Get Pricing     (HTTP Connector)

Later step reads: {{getInventory.response.data.stock}}, {{getPricing.response.data.price}}

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.