The Iterator module in Make.com takes an array and turns each item into a separate bundle. Modules placed after the Iterator can then process those bundles individually, such as creating one record per item, sending one message per recipient, or updating one file at a time.
The important design point is that an Iterator is not a general-purpose loop that repeats a scenario indefinitely. It is a fan-out step: one incoming bundle containing an array becomes multiple outgoing bundles. Every downstream path must therefore be designed for repeated execution, and the number of items in the array can directly affect processing volume.
Use an Iterator when the work needs to happen separately for each item. If you only need to transform the whole collection, keep it as an array instead. This distinction helps prevent unnecessary operations, confusing mappings, and workflows that are difficult to monitor.
What the Iterator module does in Make.com
An Iterator separates an array into individual bundles. For example, if a webhook contains an array of five line items, the Iterator can emit five bundles. A module after it receives the current line item rather than the complete original array.
The output bundle usually contains the fields belonging to one array item. If the array contains objects, fields such as an item ID, name, quantity, or email address become available for mapping in later modules. If the array contains simple values, the Iterator exposes the current value instead.
An Iterator changes the unit of work from “the collection” to “one item at a time.” Every downstream module should be evaluated against that new unit of work.
When to use an Iterator
Use an Iterator when each item requires its own action, decision, or record. Common examples include:
- Creating a task for every item in a submitted list.
- Sending a separate notification to each recipient.
- Updating CRM records from a list of changes.
- Uploading or processing multiple files returned by another module.
- Calling an API once for each product, contact, order, or identifier.
Do not add an Iterator simply because a previous module returned multiple values. A search or list module may already produce multiple bundles. In that case, adding another Iterator can be redundant or may target the wrong data structure.
A useful diagnostic question is: Does the next action need one execution per array item, or can it work with the complete array? If the complete collection is sufficient, use an array transformation or pass the array forward. If each item needs a separate downstream action, an Iterator is usually appropriate.
Many inefficient scenarios confuse “multiple values” with “an array that must be iterated.” Confirm the data shape before adding a module. The right structure may already be available as individual bundles.
How arrays and bundles relate
The Iterator requires an array as its input. Arrays commonly come from a webhook payload, a data structure, an aggregator, or a module that returns a list inside one bundle.
There are three related but different concepts:
- Array: a collection stored inside a bundle.
- Bundle: one unit of data passed between modules.
- Iterator output: multiple bundles created from the items in one array.
Suppose a previous module returns one bundle containing an array called items. Before the Iterator, the scenario still has one incoming bundle. After the Iterator, it may have one outgoing bundle for each element in items. A field from the current element can then be mapped into the next module.
Mapping the array itself is different from mapping a property inside one array item. The Iterator should receive the complete array, not a single value such as one item name or one array index. If the mapped value is not an array, the module cannot fan it out as intended.
How to configure an Iterator
Testing with realistic sample data matters. A sample containing one item can hide problems that appear with empty arrays, missing fields, duplicate identifiers, or unusually large collections.
Mapping Iterator output into later modules
After the Iterator, map fields from the current bundle into the next module. For example, a database or CRM module might use the current item’s ID, name, and status. That module will be evaluated for each bundle that reaches it.
Filters and routers can be used after the Iterator when different items need different treatment. A filter might allow only items with a particular status to continue. A router might send different item types to different processing paths. This is often clearer than placing complex conditional logic inside a single downstream module.
Be deliberate about missing values. If one item lacks an email address, a later email module may fail or produce an incomplete action. A filter, validation step, or error-handling route should define what happens to incomplete items.
Use an Iterator
Choose this when every item needs its own API call, record update, message, file action, or business decision.
Use the array as a whole
Keep the array intact when the receiving module accepts the full collection or when the required operation is a single batch transformation.
Controlling execution volume and scenario risk
An Iterator can expand one input into many downstream executions. If an array contains 200 items and three modules follow it, those modules may each process many bundles. The practical effect depends on filters, routes, errors, and the modules in the path, but array size should always be treated as an operational input.
Before enabling a scenario, decide:
- What is the expected maximum number of items?
- Which items should be skipped before expensive actions?
- What should happen when one item is invalid?
- How will a failed item be identified and retried?
- Does the business process need one large run or smaller batches?
Where possible, reduce the collection before the Iterator. Use source-module search conditions, validation, or an earlier filter to avoid creating work for items that cannot be processed. Do not rely on a later module to reject data after several unnecessary steps have already run.
Array size is not just a data detail. In an automated workflow, it is also a workload forecast.
Iterator troubleshooting
No bundles are produced
Run the source module by itself and inspect the output. Confirm that the mapped field exists, contains an array, and includes at least one item. An empty array can correctly result in no Iterator output. Also check whether a prior filter removed the bundle before it reached the Iterator.
The wrong fields appear
Inspect the structure of one array item rather than guessing field names. Confirm that the Iterator is receiving the intended array and that later modules map fields from the Iterator output instead of from the original source bundle.
Too many operations are consumed
Count the items entering the Iterator and review every module after it. Check for duplicated routes, nested Iterators, and modules that should have been placed before the fan-out step. Add filters before expensive actions and consider whether the whole collection can be processed in one operation.
One invalid item interrupts the process
Define an explicit handling path for incomplete items. Validation before the main action can separate valid and invalid data. Error handling can then record the item, notify an owner, or allow the remaining items to continue where that behavior is appropriate.
A practical design sequence
A reliable Iterator scenario can be designed in this order:
- Define the business action that must happen per item.
- Identify the array and document the expected item fields.
- Decide which items qualify before creating expensive work.
- Add the Iterator and verify its emitted bundles.
- Map one current item into the downstream action.
- Test empty, single-item, multi-item, and incomplete-item cases.
- Define ownership for failures, retries, and exceptions.
- Review execution volume and reporting before the scenario is scheduled.
For example, imagine a hypothetical order workflow that receives one order containing several line items. If each line item must create a separate inventory request, an Iterator is appropriate. A filter could exclude cancelled lines, while an error route records items missing a product identifier. If the inventory system accepts the complete line-item array in one request, iterating would add unnecessary work and should be avoided.
The Iterator is a small module, but its placement affects data structure, execution volume, error handling, and ownership. Treat it as a process-design decision rather than a mapping convenience. Broader automation and systems implementation services can help when a scenario has grown beyond a clear, testable workflow. For a wider view of how connected systems should support operational work, see ConsultEvo’s systems, CRM, automation and AI consultancy.
Frequently asked questions
What does the Iterator module do in Make.com?
The Iterator takes an array stored in an incoming bundle and emits one separate bundle for each item. Modules after it can then process those items individually.
What is the difference between an Iterator and multiple bundles in Make.com?
An Iterator splits one array inside a bundle into multiple bundles. A search or list module may already produce multiple bundles, so an Iterator is not always required.
Why does a Make.com Iterator produce no bundles?
The mapped field may be empty, missing, or not an array. Run the preceding module, inspect its raw output, and confirm that the Iterator receives the complete collection.
How can I reduce operations after an Iterator?
Reduce the array before it reaches the Iterator, filter out items that do not qualify, avoid unnecessary nested Iterators, and confirm that the downstream action cannot process the collection as a batch.
Can an Iterator process nested arrays in Make.com?
It can, but nested arrays usually require deliberate additional structure and careful testing. Use another Iterator only when the business process genuinely requires work for each item inside each parent item.
Make your Make.com scenarios easier to operate
If an Iterator is exposing unclear data structures, excessive execution volume, or unreliable handoffs, ConsultEvo can help clarify the process, ownership, and automation design before adding more modules.