Loop

This guide explains how to configure and use the Loop node in your automation workflows to process collections of items one at a time, running a sub‑workflow for each.

---

1. Purpose

• The Loop node allows you to iterate over an array (or numeric count) and execute a sequence of downstream tasks for each item sequentially.
• Unlike parallel forks, it guarantees that all tasks in one iteration complete before starting the next.

---

2. Configuration

2.1 Required Inputs

Input Name	Type	Description
Array Object	text	An expression that evaluates to a list/array. Use placeholders ({...}) to reference workflow data.
Count	number	(Alternative) An integer N. If provided and Array Object is empty, the loop runs N times (items 1 to N).

Note: Exactly one of Array Object or Count must be set.

2.2 Optional Outputs

The Loop node itself writes these into task data, making them available to downstream tasks:

• LoopItem: the current item (object) being processed.
• IterationIndex: zero‑based index of the iteration.
• IterationCount: total number of iterations.

---

3. Sub‑Workflow Design

1. Next branch: Connect your first child task to the Loop node using a dependency route named Next (case‑insensitive). This child will be cloned and run for each item.
2. Sub‑tasks: Chain any number of downstream tasks (e.g. "Get Data", "Check If", "Insert Row") off the first child using normal dependency routes (Completed, specific status names, or switch outputs).
3. Finished branch (optional): If you need a wrap‑up once all iterations are done, connect a task to the Loop node with a route named Finished (case‑insensitive).

[Loop]
   └─ (Next) → [FirstTask] → [SecondTask] → ...
   └─ (Finished) → [CleanupTask]

---

4. Execution Flow

1. Initialization: Evaluate Array Object or Count and store items as LoopItems.

2. Iteration Loop:

   • For i from 0 to IterationCount - 1:

     1. Clone the Next child task, stamp LoopItem = LoopItems[i] and IterationIndex = i.

     2. Execute its entire subgraph synchronously:

        • Run each task in order, matching routes by statusReturn or Default if a switch or if‑node is used.
        • Support for AndOperator joins: waits until all upstream tasks complete before executing.

     3. When the subgraph ends, move to the next iteration.

3. Finished branch: if defined, run its tasks once after all iterations.

---

5. Special Nodes within Loop

• If/Switch: Tasks with multiple outgoing routes (e.g. Apple, Banana, Default). The engine picks the branch whose route name ends with the task’s statusReturn value (case-insensitive). Fallback to Default if no exact match.
• AndOperator: Joins multiple upstream branches. It will wait until all parent tasks have finished and then merge their outputs into a single input dictionary before running.
• Loop: Nested loops are supported; each loop runs its sub‑workflow fully before outer loop continues.

---

6. Error Handling & Termination

• Task failure: any task returning taskSuccess = false will cancel the entire workflow.
• QueueWorkflow: if a task named QueueWorkflow completes, the workflow stops with status Accepted (202) and triggers a new workflow.
• DataReturnObject: if a task named DataReturnObject completes, the workflow stops immediately, returns its ReturnData via the API (status 200), and does not continue looping.

---

7. Example

8. Troubleshooting

• No iterations running: ensure your Array Object expression yields a non-empty list or provide a valid Count.
• Sub‑tasks running in parallel: verify you’re using the documented sequential engine (Next/Finished branches).
• AndOperator not waiting: ensure all parent tasks use distinct taskIds and their outputs have been stored in the workflow before the join.

---

For more details or support, visit our Knowledge Base or contact the Automation team. Happy looping!