Make Iterator & Array Aggregator, Explained

People keep asking me: "Hey Manuel, what is an Iterator, what is an Aggregator – and when do I actually need them?" Fair question. Make's own documentation tells you what the modules do, but not when to reach for them or which settings quietly break your scenario. So here's the full picture – how they work, every setting explained in plain language, and the four mistakes I see most often – so you never have to ask again.

One note before we start, in case you got here from an old bookmark: Make is the tool formerly known as Integromat (renamed in February 2022). Same platform, same modules – everything below applies whether you learned this stuff as Integromat or not.

Last updated: 27 July 2026, checked against the current Make UI and Make's own module reference.

The short answer

• An Iterator takes an array (a list inside one bundle) and splits it into one bundle per item. Every module after it then runs once per item.
• An Array Aggregator does the opposite: it collects many bundles and merges them into one bundle containing an array.
• A Numeric Aggregator merges many bundles into a single number – using SUM, AVG, COUNT, MAX or MIN.
• Rule of thumb: iterate as late as possible, aggregate as early as possible. Every bundle that travels through your scenario multiplies your credit consumption (more on that below).

Now the long answer, with a real scenario you can rebuild.

Arrays, bundles and why you need an Iterator at all

Here's the sample scenario: we request a five-day forecast from the OpenWeatherMap API and write it into Google Sheets.

The API answers with one response that contains a list of time entries, each with its own forecast:

That list is an array. You can recognise arrays everywhere in Make by the square brackets in the mapping panel:

Two properties of arrays matter here:

1. An array lives inside a single bundle. The API module outputs one bundle, and the 40 forecasts are packed inside it as a list.
2. An array is dynamic. Today it holds 40 entries, tomorrow 12, sometimes 0. You can't hard-wire your scenario to a fixed count.

Arrays of collections vs. primitive arrays

Make distinguishes two kinds of arrays, and several settings behave differently depending on which one you have:

• Array of collections – each item is a bundle-like object with named fields. Our forecast list is one: every entry has a date, temperature, humidity and wind speed.
• Primitive array – each item is just a bare value: a list of numbers ([4, 8, 15]) or strings (["a@b.com", "c@d.com"]). Email recipient lists and tag lists are typical examples.

An Iterator handles both: with a collection array, each output bundle carries the item's named fields; with a primitive array, each output bundle carries the item as a single value.

The trap: mapping an array item directly

In the mapping panel you can click on an item underneath an array – but that maps only the first entry of the array, not all of them:

This is the classic beginner symptom: the scenario runs without errors, but only one row lands in your sheet. To process all items, you have to split the array first. That's the Iterator's job.

When you actually need an Iterator – and when you don't

Before you add one, check whether you need it at all. Three cases:

• Your data already arrives as separate bundles – search and "watch" modules (Google Sheets Search Rows, most triggers) output one bundle per record by design. No Iterator needed; the modules after them already run once per record.
• You only need a total or a combined value – if all you want is a sum, a count or a joined string, you often don't need to iterate at all. Built-in functions like sum(), length() and map() work directly on arrays inside a single mapping field and cost you nothing extra.
• You have an array inside one bundle and need to do something per item – write a row, send a message, create an invoice line. This is the Iterator case.

That third case is exactly our weather scenario, so let's build it.

By the way – if you want to click along and don't have a Make account yet, you can create one for free here.

Transparency: This is a referral (affiliate) link. If you use it, we may earn a commission – the price you pay stays the same.

Step by step: the Iterator in action

Add the Iterator module (under Flow Control in the tools section). It has exactly one important field: Array – the array you want to split.

Map the List array from the weather module into that field, then run the scenario once. Check the Iterator's output: in comes one bundle with an array of 40 items –

– and out come 40 separate bundles, processed one after another by everything that follows:

One thing people forget: re-map the modules after the Iterator. Your Google Sheets module must now use the Iterator's output values (which update dynamically per bundle), not the original API fields (which would again give you only the first entry):

Run it once, and all 40 forecasts appear as rows in the sheet:

That's the whole Iterator: array in, one bundle per item out. The Aggregator is the mirror image – it puts everything back together:

The Array Aggregator, setting by setting

An aggregator waits until all incoming bundles have arrived, merges them, and sends one bundle onwards. The Array Aggregator is the general-purpose version – its output is one bundle containing an array. Here's what each setting actually means:

Source Module – the module where the bundles you want to merge start. Everything between the source module and the aggregator runs once per bundle; the aggregator collects the results. If your aggregation looks wrong, check this first – a wrong source module merges the wrong scope of bundles.

Target structure type – what the items in the output array should look like. Custom lets you tick the fields you want to keep. But the real power move: if a later module expects a specific array format (say, an invoice module expecting line items), select that module's field as the target structure, and the aggregator shows you exactly the fields that module needs. Most "my aggregator output doesn't fit" problems are just a Custom structure where a target-module structure belonged.

Group by – optional formula or field. Instead of one big array, the aggregator outputs one bundle per distinct value of the formula. Example: group order items by warehouse, and you get one aggregated bundle per warehouse.

Stop processing after an empty aggregation – by default (unchecked), an aggregation with zero incoming bundles still outputs one bundle with an empty array, and your scenario continues. Checked, the aggregator outputs nothing and the route stops there. Check it when "continue with an empty list" would cause damage – like emailing a customer an empty order confirmation.

Aggregating into a primitive array (numbers or strings)

Note that the Array Aggregator always outputs an array of collections – items with named fields. If a later module expects a plain array of values (just numbers or just email addresses), aggregate first, then unwrap the values with the map() function on the aggregator's output. For pure text output (one string instead of an array), use the Text Aggregator instead – it joins all bundles into a single text with a separator you choose. Make also ships Table, CSV and JSON aggregators for those specific output formats; they all follow the same source-module logic.

Here's the Text Aggregator from our weather scenario, combining temperature, weather type and description with a New row separator –

– and its output: all 40 forecasts as one text block, ready to send as a single Slack message or email:

The Numeric Aggregator: SUM, AVG, COUNT, MAX and MIN

Several of you found this article searching for exactly this, so here's the reference the docs make you dig for. The Numeric Aggregator merges many bundles into one number. You map a single numeric value from the incoming bundles and pick one of five aggregate functions:

Worked example: your order comes in with a line-items array. Iterator splits it, a Numeric Aggregator with SUM on price × quantity gives you the order total in one bundle – ready to map into your invoice. Want the most expensive item for an upsell message? Same setup, function MAX on the price. Need both? Use two aggregators – each Numeric Aggregator applies exactly one function to one value.

The four classic mistakes (and how to avoid them)

1. Mapping the first array item instead of iterating. The symptom: no errors, but only one row/message/record ever gets created. The cause: clicking an item under the array in the mapping panel maps entry number one, full stop. Fix: Iterator.

2. Aggregating too late – or iterating for no reason. Every module between Iterator and Aggregator runs once per item. A 50-item array passing through four modules before aggregation costs 200 credits per run; aggregate after one module and it's 50. And if you never needed per-item actions – just a total – sum() in a mapping field costs zero extra. Design the narrow part of the hourglass as early as you can.

3. Losing your fields after the aggregator. After an aggregator, earlier fields are gone from the mapping panel – only what you aggregated travels on, packed inside the array. This is by design: many bundles became one, so per-bundle values no longer exist. Fix: include every field you'll need later in the aggregated fields (or in the target structure), or map values that exist outside the iterated section.

4. Not planning for the empty array. An order with zero line items, a day with no new leads: the Iterator outputs zero bundles, so downstream modules simply never run – which either silently skips work or (with Stop processing after an empty aggregation unchecked) hands an empty array to a module that chokes on it. Decide explicitly: filter empty arrays out early, or set the aggregator's empty-aggregation behaviour on purpose.

What Iterators and Aggregators do to your credit bill

Quick terminology bridge, because most tutorials are older than August 2025: Make no longer bills in "operations" – the billing unit is now credits. The conversion is painless: one action (what used to be one operation) still costs one credit. The new unit exists because you can now run AI models directly inside Make, and – in practice, as certified Make trainers we see this in client accounts daily – AI actions consume fractional, uneven credit amounts where classic actions are always whole numbers. If AI inside your scenarios is on your radar, here's what AI agents actually are beyond the buzzword.

For Iterators and Aggregators, the math is simple and worth knowing by heart:

• The Iterator itself counts as one action – one credit – no matter whether it outputs 3 bundles or 3,000.
• Every module after it runs once per bundle. A 200-item array flowing through three modules = 600 credits, every single run.
• The Aggregator ends the multiplication: after it, you're back to one bundle, and modules cost one credit again.

This is why scenario design beats plan choice: the same business result, aggregated one module earlier, can cut a scenario's monthly credit bill by hundreds of thousands of credits. If you want to see what those credits translate to in money, here's our current breakdown of Make's pricing and the credit model.

Real-world example: WooCommerce order line items

Ecommerce is where this pattern earns its keep. A WooCommerce order arrives, and you never know in advance how many products it contains – the line items are an array inside the order (square brackets again):

The pattern: Iterator splits the line items → per item, a row goes into the inventory sheet → Array Aggregator (target structure: the invoice module's line-item field) merges them back → one invoice is created in QuickBooks:

Split, act per item, merge, continue with one bundle. Once you see that hourglass shape, you'll recognise it in half the scenarios you build.

Wrap-up

Iterator: array → bundles. Array Aggregator: bundles → array. Numeric Aggregator: bundles → one number (SUM, AVG, COUNT, MAX, MIN). Iterate only when you act per item, aggregate as early as possible, plan for the empty array – and your scenarios will be both correct and cheap to run.

Diesen Guide gibt es auch auf Deutsch.

And if you'd rather have someone design these scenarios for you – credit-efficient, error-handled, documented – that's literally what we do.