Make.com Iterators and Aggregators, Explained Simply

This is the point where a lot of people stall. Everything worked while each run handled one thing, and then a record arrived carrying a list inside it: three attachments, twelve line items, forty search results. Suddenly the mapping panel offers you something that will not go into a text field.

The concept is simpler than the interface makes it look. Make moves data as bundles, roughly one record each. An array is a list living inside one bundle. The Iterator opens that list up, and the aggregator closes it back down.

What is an array in Make, and how do you spot one?

An array is a list of items held inside a single bundle. In the mapping panel it appears as a numbered group rather than a plain value, and the giveaway is that the items are indexed: item one, item two, item three, all under the same field name.

Email attachments are the classic case. One email is one bundle, but the attachments field holds however many files were attached. Order line items, tags, search results, and the rows returned by a spreadsheet lookup all behave the same way.

Not every list needs an Iterator. Some modules already hand you separate bundles, and some apps ship their own shortcut. Make's documentation gives the example of an email module that iterates attachments directly, producing the same result without you specifying the array by hand. Check the app's own module list before adding a general Iterator.

What does the Iterator actually do?

Make's documentation describes the Iterator as a special type of module that converts an array into a series of bundles, where each array item is output as a separate bundle. Everything after the Iterator then runs once per item instead of once per record.

It has essentially one setting, the Array field, and that field is where you map the list you want opened up. The attachments example in their documentation splits an array of attachments into single bundles so that each one can be saved to a folder in turn.

What does an aggregator do?

An aggregator does the reverse. Make's documentation describes it as a module that accumulates all the bundles it receives during a single source module operation and outputs one bundle containing an array, with one item for each bundle it collected.

The setting that decides everything is Source Module, which their documentation defines as the module from which the bundle aggregation will start. Once you set it, the canvas draws a grey area around the path between that module and the aggregator. That grey band is the loop, and it is the fastest way to check you aggregated what you meant to.

The Array aggregator also offers Group by, which splits the output into groups based on a formula you supply, and Stop processing after an empty aggregation, which controls whether anything is produced when no bundles arrived. The second one is worth knowing before you wonder why an empty run still posted a message.

Make's own how to guide describes a third piece, the target structure, meaning how you want the aggregated data to appear in the app that receives it. You can define a custom structure or pick a structure that the next module already expects, which saves mapping work later.

Splitting a list and putting it back together

1. Run the scenario once with real data — The modules above need to know their own output shape before the Iterator can show you anything useful. Do this first and the rest of the build is straightforward.
2. Check whether you need an Iterator at all — Look at the source app's module list for a ready made iterate option, and check whether the module already returns separate bundles. If either is true, skip the next step.
3. Add the Iterator — Insert it from the flow control tools, then map the array you want opened into its Array field. Nothing else needs configuring.
4. Build the per item work — Add the modules that should run once per item. Their fields now map from the Iterator's output, which represents one item rather than the whole list.
5. Add the aggregator — Place it after the per item work, then set Source Module to the module where the loop should start, usually the Iterator itself. Watch for the grey band on the canvas.
6. Define the target structure — Choose which fields from each bundle should become the items in the resulting array, shaping it for whatever module comes next.
7. Add the single final action — This is the module that should run once rather than once per item: the one summary message, the one bulk write, the one file.
8. Test with a record that has two items, then one, then none — Most aggregator bugs only appear at the edges. An empty list and a single item list break more scenarios than a list of fifty.

That is eight steps to handle one list, which is honest work but it is still work. At Sistava the same job is a sentence: here is the list, here is what to do with each item, come back to me if something looks wrong.

Why do iterators make your bill jump?

Because operations are counted per bundle processed, and an Iterator multiplies bundles. Make defines an operation as a single module run to process data or check for new data, and states that a module's number of operations depends on how many bundles it processes.

Their documentation gives a worked example that makes the arithmetic obvious. A scenario triggered by a form with ten new responses, followed by three modules, comes to thirty one operations: one for the trigger, then ten for each of the three modules below it.

Apply that to an Iterator and the picture is clear. Five modules after an Iterator that opens a twenty item list is a hundred module runs from one record. This is exactly why aggregating matters: collapsing twenty bundles into one before a write means one write instead of twenty.

When is all this loop building worth it?

When the per item work is genuinely mechanical, this is a good use of an afternoon. Save each attachment. Create a row per line item. Post one digest instead of forty pings. Make handles that shape well, and the grey band on the canvas makes the loop readable to whoever inherits it.

It gets awkward when the per item work needs a decision. Summarise each attachment and only file the ones that matter. Read each line item and flag the ones that look wrong. That is not a mapping problem, and iterating over it just means you now make the same difficult decision twenty times per run.

Set-up work like this is exactly what we removed at Sistava. Rather than opening a list, looping over it, and collecting it back up, you hire an AI Employee and tell it in plain English what the list is and what you want done with it. It has the tools connected already, it asks you when it is unsure, and it sets itself up.

Both have their place. A predictable list with predictable handling belongs in an Iterator. A list where each item needs reading before you know what to do belongs with something that can read.

What goes wrong with iterators and aggregators?

The failures cluster tightly, and nearly all of them show up as a bundle count that does not match what you expected. Check the counts on each module in the run history before you change anything.

• The Array field mapped to the wrong level, so the Iterator opens a container rather than the list you meant.
• Source Module set to the wrong module, so the aggregator collects a different stretch of the scenario than the grey band suggests.
• An empty list, where nothing reaches the aggregator and the scenario either outputs nothing or outputs an empty result you did not plan for.
• An Iterator added when the app already offered a ready made iterate module or already returned separate bundles.
• The final write left inside the loop, so it fires once per item and the operations bill goes up by the length of the list.

Sources

• Make Help Center, Iterator, for the Array field, per item bundles, and the missing structure case.
• Make Help Center, Aggregator, for Source Module, Group by, and empty aggregation behaviour.
• Make Help Center, Operations, for the per bundle counting rule and the thirty one operation example.
• Make, How to use the Iterator and Array aggregator, for the target structure step.
• The AI Automators, Iterators and aggregators in Make, an independent guide covering text aggregation into one message.
• Consultevo, Make Iterator and Array aggregator guide, for practical notes on empty arrays and unexpected structures.