Iterator in Automation

Sometimes an automation receives not one record but a list of them. An iterator is the step that handles this situation, taking each item in a list and running the rest of the workflow on it individually, one at a time.

Without an iterator, automation steps designed for single records fail or only process the first item when they receive a list.

Key Takeaways

• Iterator: an automation step that loops through a list of items and processes each one individually using the same subsequent steps.
• Handles multi-item data: when a trigger or API response returns multiple records, an iterator separates them for individual processing.
• One item at a time: the steps after the iterator run once for each item in the list, not once for the entire list.
• Common use case: processing every row in a spreadsheet, every order in a list, or every contact in an API response.
• Different from a single step: without an iterator, a step will either fail on a list or process only the first item.

What Does an Iterator Do in Automation?

An iterator takes a list of items from a previous step and feeds each item individually into the next step in the workflow. The steps that follow the iterator run once per item, repeating until every item in the list has been processed.

Think of an iterator as a loop. It keeps running the same steps until the list is exhausted.

• Input: a list or array of items from a trigger, an API response, or a previous step that returned multiple records.
• Processing: the iterator takes item one, runs all subsequent steps for that item, then moves to item two, and continues.
• Separate processing: each item is treated as an independent record by the steps that follow; they do not see the other items in the list.
• Output per item: every run of the subsequent steps produces its own output for that specific item in the list.
• End of list: when all items have been processed, the iterator stops and the workflow completes.

When Should You Use an Iterator in Automation?

Use an iterator when a step in your workflow returns a list of items and the next step needs to act on each item individually. Without an iterator, multi-item data cannot be processed record by record.

Lists appear frequently in automation, especially when pulling data from APIs or databases.

• API responses with multiple records: a GET request to a CRM returns ten contacts; an iterator processes each contact through the same follow-up steps.
• Spreadsheet row processing: an iterator loops through every row in a sheet and performs the same action, like creating a record, for each one.
• Order item processing: an order object contains multiple line items; an iterator processes each item to update inventory or trigger a fulfillment action.
• Batch notification sending: a list of user IDs needs a notification sent to each one; an iterator sends the notification individually per ID.
• Multi-file processing: a folder contains several documents; an iterator processes each file through the same transformation or analysis steps.

If you find yourself wondering how to process every item in a list, an iterator is almost always the answer.

How Do You Configure an Iterator in Automation?

To configure an iterator, add the iterator step after the step that produces the list, then select the list or array field as the input. The steps you add after the iterator will automatically receive one item at a time from that list.

Platforms use different names for this concept. Make calls it an iterator; Zapier handles it through looping steps and array handling; n8n uses a split-in-batches node.

• Identify the list source: find which previous step produces the array or list of items you need to process individually.
• Add the iterator step: insert the iterator or loop step immediately after the step that produced the list.
• Select the array field: choose the specific list or array field in the iterator configuration that the workflow should loop through.
• Build the loop body: add the steps that should run for each item directly after the iterator; they will run once per item automatically.
• Test with a small list: when testing, use a list with two or three items to confirm the iterator processes each one correctly before running on full data.

Make's iterator module documentation explains how to configure iterators in a visual workflow context.

What Is the Difference Between an Iterator and a Batch Processor?

An iterator processes one item at a time sequentially. A batch processor groups items into sets and processes each set together. Iterators are simpler and work for most use cases; batch processing is used for high-volume workflows where sequential processing would be too slow.

Both handle lists, but in different ways and for different reasons.

• Iterator: processes item one, completes, then processes item two, and so on until the list is finished.
• Batch processor: groups items, such as fifty at a time, and processes each group together rather than one at a time.
• When to use iterator: suitable for most automation workflows where list sizes are manageable and sequential processing is acceptable.
• When to use batch processing: better for very large lists where processing one item at a time would take too long or approach API rate limits.
• Platform differences: some platforms have dedicated batch steps; others handle this through configuration options in the iterator or loop step itself.

For most SMB automation workflows, a standard iterator handles list processing correctly without needing batch configuration.

What Are Common Iterator Mistakes in Automation?

Common mistakes are applying the iterator to the wrong field, nesting iterators without planning for execution time increases, and not accounting for empty lists which can cause the iterator to produce no output without any visible error.

Iterator errors often produce silent failures or unexpected behavior.

• Wrong field selection: selecting the parent object instead of the specific array field inside it means the iterator receives one object instead of a list.
• Nested iterators: placing an iterator inside another iterator multiplies execution time and can hit platform operation limits quickly.
• Empty list handling: if the list is empty, the iterator simply does not run; add a check step before the iterator to handle this case explicitly.
• Rate limit exposure: iterating through a large list that makes an API call for each item can hit the destination API's rate limit quickly.
• Missing error handling: if one item fails during processing, the iterator may stop for the rest of the list without alerting anyone.

Conclusion

An iterator is what makes automation practical for real-world data, which almost always comes in lists rather than single records. It loops through each item, processes it individually, and moves on. Understanding when to use an iterator and how to configure it correctly is one of the most useful skills for anyone building workflows that handle more than simple one-to-one data transfers.

Building Automation That Handles Lists and Multi-Record Data Correctly?

Most real business data comes in sets, not single records. Iterators are how you process it properly.

LOW/CODE Agency is the AI product development partner built for SMBs. We build and ship automation systems, AI agents, web apps, and mobile apps. Our team understands how to build workflows that handle multi-item data reliably, including iterator logic, error handling per item, and rate limit management. We have delivered 450+ projects for clients including Medtronic, Coca-Cola, and American Express.

• List data architecture: we identify every point in your workflow where multi-item data appears and design the right iterator structure for each.
• Array field mapping: we confirm the iterator is configured on the correct list field so every item in the list is processed, not just the parent object.
• Per-item error handling: we add error logic inside the iterator loop so one failed item does not stop the entire list from processing.
• Rate limit management: we design iterator loops that respect API rate limits so large-list processing does not get blocked mid-run.
• Empty list handling: we add pre-iterator checks so empty lists produce a defined response rather than silently producing no output.
• Performance review: we evaluate whether sequential iteration is sufficient or whether batch processing would be more appropriate for your data volumes.

If your automation is not processing every item in a list the way it should, talk to LOW/CODE Agency and we will fix the loop logic correctly.