Agiled Docs

For Each nodes repeat the next part of the workflow for every item in a selected collection.

Use For Each when a trigger or earlier step produces a list, such as items, contacts, invoice line items, or another array of records.

Use loops only when every item should receive the same downstream treatment. If items need different logic, add conditions inside the loop or split the workflow.

Avoid loops when the collection size is unpredictable. A large list can create many tasks, notifications, provider calls, or customer-facing messages from one trigger.

Add A For Each Node

Open the workflow builder.
Add For Each from flow control.
Choose the collection to iterate over.
Set concurrency if the field is available.
Connect the downstream steps.
Test with a safe record that contains a small collection.

Use Carefully

For Each can create many actions from one trigger. Start with a small data set and check run detail before using it on production workflows.

For customer-facing actions, test with a collection of one or two items before running against larger records.

Review the run detail after the first real loop. Confirm item count, success count, skipped items, and any failed item before increasing volume.

Collection and Concurrency

The collection field should point to the array you want to loop through, such as items, contacts, or invoice.line_items.

Concurrency controls how many items are processed at once. Use 1 for safest ordering. Higher numbers can run faster but process items in parallel. The value must be a whole number greater than zero.

If the downstream action calls an external provider, starts customer communication, or creates billable records, keep concurrency low until several runs prove the provider and workflow can handle the volume.

Test Item Output

After the first test run, open run detail and inspect one successful item and one skipped or failed item if present. Confirm each loop item has the fields the downstream steps expect before increasing collection size or concurrency.

Design Safe Loops

Before publishing a loop, decide how duplicates will be avoided. A loop that creates one task per checklist item should not create the same tasks again every time the trigger record is edited.

Use conditions before the loop when only some records should be processed. Use conditions inside the loop when the workflow needs to inspect each item before taking action.

For customer emails, invoices, provider updates, and payment-related actions, run a test with internal recipients or test records first. Confirm the exact number of actions created from one trigger.

Good Uses

Create one task for each submitted checklist item.
Notify one owner for each selected account.
Process invoice line items.
Attach or update several related records from one trigger.

Avoid

Running loops over unbounded lists.
Sending customer emails in parallel before testing.
Creating records without an idempotency or duplicate-checking strategy.
Using high concurrency when order matters.

Use conditions inside the loop when some items should be skipped. It is safer to skip intentionally than to let downstream steps fail for items that never needed action.

Troubleshooting

If a loop processes too many items, pause the workflow and inspect the selected collection. The trigger may be passing a broader list than expected.

If duplicate records are created, add a duplicate-checking strategy or make the downstream action idempotent before running the workflow again.

Pause the workflow before cleanup if the trigger can fire again while you are fixing duplicate loop output.

Use For Each Steps