Configuration
Configure the Loop node's source collection variable and understand per-iteration execution memory injection.
Minimal configuration: The Loop node requires only one configuration property — the name of the workflow variable that contains the array to iterate. All per-iteration state (current index and current item) is automatically injected into execution memory before each body execution.
Properties
| Property | Type | Required | Default | Description |
|---|---|---|---|---|
items |
string (variable name) | Required | none | The name of the workflow variable that contains the array to iterate over. The variable must hold an array value at the time the Loop node executes. Supports dot-notation for nested variables (e.g., order.lineItems). If the variable is null, undefined, or not an array, the loop body never fires and execution proceeds directly to the done port. |
Per-Iteration Execution Memory
Before each execution of the loop body, the Loop node injects the following fields into the execution memory. These are available to all nodes within the loop body via the standard $var and $ctx access patterns:
| Memory Key | Type | Description |
|---|---|---|
current_index |
integer (0-based) | The zero-based index of the current item in the array. The first iteration has current_index = 0, the last has current_index = array.length - 1. |
current_item |
any (matches array element type) | The value of the current array element. For an array of objects, this is the full object. For an array of strings, this is the string value. Access properties of object items using dot notation in downstream expressions: $var.current_item.productCode. |
Materialised List Behaviour
When the Loop node begins execution, it reads the entire contents of the specified variable into an internal materialised list before starting iteration. This means:
- The number of iterations is fixed at the time the loop starts — if upstream logic adds or removes items from the source variable while the loop is running, those changes do not affect the current loop.
- Memory usage scales with the size of the collection. For very large collections (thousands of items), consider whether a chunked or paginated approach is more appropriate for your use case.
- The source array variable is not modified by the loop. If you need to accumulate results, use a separate accumulator variable initialised before the loop.
Break and Continue Signal Handling
The Loop node monitors the execution memory for two special signal flags set by Break and Continue nodes within the loop body:
| Signal Flag | Set By | Effect on Loop |
|---|---|---|
LoopBreakSignal |
Break node | Terminates iteration immediately. No further body executions occur. The done port fires with the accumulated context. |
LoopContinueSignal |
Continue node | Skips the remainder of the current iteration's body and advances to the next item. The loop advances current_index and fires the body port for the next element. |
Variable isolation: The
current_index and current_item variables are overwritten at the start of each iteration. Do not rely on their values after the loop completes — they will hold the values from the final iteration. If you need to track which items were processed, accumulate results into a separate variable during the loop body.
Tip — Initialise accumulators before the loop: Use a Set Variable node before the Loop node to initialise accumulator variables (e.g.,
processedCount = 0, errors = [], totalAmount = 0). Nodes in the loop body can then read and update these accumulators. After the loop's done port fires, the final accumulated values are available for downstream processing.