Menu
Connectors
For Loop Connector
Iterate over an array (For Each) or repeat until a condition is met (Do While), running nested workflow steps each time.
On this page
What this connector is for
Repeats a sequence of nested steps, either once per item in an array (For Each) or while a condition stays true (Do While). To stop a loop early from inside its own body, see Break Loop; to skip an iteration based on a condition without stopping the loop, wrap the relevant nested steps in a Conditional Branch instead.
For Each
Iterates over an array, running the nested steps once per item.
Configuring it
- Array Source (
arraySource) — required. A{{...}}expression resolving to an array (e.g.{{listProducts.response.data.items}}or{{trigger.body.products}}) — see Step Reference. A JSON array string is also accepted and parsed automatically. - Item Variable Name (
itemVariable) — the name nested steps use for the current item. Defaults toitem. - Index Variable Name (
indexVariable) — the name nested steps use for the current (0-based) index. Defaults toindex. - Total Count Source (optional) (
totalCountSource) — a{{...}}expression for the total record count if known upfront (e.g.{{listProducts.response.data.meta.results.total}}), enabling "X of Y processed" progress in batch jobs. Leave blank if unknowable ahead of time — processed-count progress still works without it. - Record Identity (optional) (
recordIdentity) — a{{...}}expression identifying this record's stable business key (e.g.{{item.sku}}), enabling cross-run history, per-record filtering, and record-scoped rerun in batch jobs. Falls back to the iteration index when unset. - Primary Progress Source (
isPrimaryProgressSource) — boolean, default off. With exactly one loop anywhere in the call graph (including loops inside called workflows/routes), a primary is picked automatically; with more than one, exactly one must set this explicitly or a batch job's top-level progress picks whichever loop happens to report first.
Inside the loop body, both the current item and index are available two ways — as bare template variables using whatever names you chose ({{item}}, {{index}}), and via this step's own reference ({{<stepReference>.item}}, or under the uniform envelope {{<stepReference>.response.data.item}}).
Reading the response
{{<stepReference>.response.data.iterations}}— how many items were actually processed.{{<stepReference>.response.data.items}}— the original array that was iterated.{{<stepReference>.response.data.results}}— an array of each iteration's last-step output, in order.{{<stepReference>.response.data.itemVariable}}/.indexVariable— the variable names configured above.{{<stepReference>.response.data.failedIterations}}— count of iterations that had a failure (only nonzero when a batch job's Continue On Iteration Error behavior kept the loop running past a failed item).{{<stepReference>.response.data.stoppedEarly}}— true if the loop stopped before consuming the whole array (execution deadline reached, or a Break Loop fired).{{<stepReference>.response.data.remainingCount}}— how many items were never reached, when stopped early.{{<stepReference>.response.data.brokenEarly}}— true specifically when a Break Loop step stopped it (as opposed to hitting the execution deadline).
For example, a loop named "For Each Line Item" (reference forEachLineItem) with Item Variable item — inside its body, {{item.sku}} and {{forEachLineItem.item.sku}} both read the current item's sku; after the loop, {{forEachLineItem.response.data.iterations}} reads how many ran.
Example
Array Source: {{trigger.body.lineItems}}
Item Variable Name: item
Index Variable Name: index
Do While
Runs the loop body first, then repeats it while a condition stays true — no array required.
Configuring it
- Continue Condition (
continueCondition) — required. Evaluated after each iteration; the loop repeats while it's true. Same recursive condition shape (single comparison, or nested AND/OR groups) as the Conditional Branch connector's own branch conditions, sharing the same operator set and{{...}}expression support — commonly checking a{{runtimeVariables.x}}value set by a step earlier in the loop body. Leaving it unset evaluates to false, so an unconfigured loop safely runs exactly one iteration. - Max Iterations (
maxIterations) — required, default1000, must be between 1 and 100000. A hard safety cap so a condition that never turns false can't run forever. - Index Variable Name (
indexVariable) — the name nested steps use for the current (0-based) iteration index. Defaults toindex. - Record Identity (optional) (
recordIdentity) — same purpose as For Each's, scoped per iteration (e.g.{{runtimeVariables.orderId}}); falls back to the iteration index. - Primary Progress Source (
isPrimaryProgressSource) — same semantics as For Each's.
There's no item variable in Do While — only the index, since there's no array driving iteration.
Reading the response
{{<stepReference>.response.data.iterations}}— how many iterations actually ran.{{<stepReference>.response.data.indexVariable}}— the configured index variable name.{{<stepReference>.response.data.results}}— an array of each iteration's last-step output, in order.{{<stepReference>.response.data.failedIterations}}— count of iterations that had a failure.{{<stepReference>.response.data.stoppedEarly}}— true only when the loop was truncated by hitting Max Iterations or the execution deadline — a false continueCondition or a Break Loop are both treated as intentional, successful terminations, not "stopped early".{{<stepReference>.response.data.reason}}— why the loop stopped:"condition_false","break","max_iterations", or"deadline".{{<stepReference>.response.data.brokenEarly}}— true specifically whenreasonis"break".
Example
Continue Condition: {{runtimeVariables.jobStatus}} equals "pending"
Max Iterations: 50
Index Variable Name: attempt
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.