Iterators vs Aggregators in Make

Iterators and aggregators are one of the clearest examples of how Make thinks about data flow.

They solve opposite problems.

One splits. One combines.

That sounds simple until a workflow fails because the wrong modules are receiving the wrong bundle shape.

Why this lesson matters

Many Make scenarios need to move between two data shapes:

• one array inside one bundle
• many bundles processed one by one
• one final combined result again

If you do not understand that transition clearly, the scenario gets harder to reason about fast.

This is why iterator and aggregator decisions are really workflow-shape decisions.

The short answer

Use an iterator when you need to turn an array into separate bundles and process each item individually.

Use an aggregator when you need to collect multiple bundles and output one combined bundle again.

In other words:

• iterator: one array becomes many bundles
• aggregator: many bundles become one bundle

The best choice depends on what the next module expects to receive.

Iterators are for item-by-item processing

Make's docs describe the iterator as a special module that converts an array into a series of bundles.

That makes it useful when each item needs its own pass through downstream logic.

Common examples:

• email attachments
• line items
• arrays of records from a parsed payload
• batch results that need separate handling

The iterator is the right tool whenever the workflow should think in terms of "one item at a time."

Aggregators are for rebuilding a combined result

Make's docs describe an aggregator as a module that merges several bundles of data into a single bundle.

That is useful when the workflow needs one final object again, such as:

• one archive file
• one array of processed outputs
• one grouped payload
• one downstream write after multiple item-level steps

This usually happens after some item-by-item processing already occurred.

The most common pattern is iterator first, aggregator later

This is the classic workflow:

1. Receive one bundle that contains an array.
2. Use an iterator to split the array into individual bundles.
3. Process each bundle.
4. Use an aggregator to merge the processed results into one bundle again.

Make's own docs use this pattern in examples like handling email attachments and then creating a combined archive.

That is the cleanest mental model for the pair.

Aggregation changes what data exists downstream

This is one of the easiest places to get tripped up.

Make's docs explicitly note that bundles output by the source module and modules between the source and aggregator are not available downstream after aggregation unless you include the needed fields in the aggregator setup.

That means aggregation is not just "pack things together." It also changes which fields survive past that point.

This is why aggregator configuration deserves more attention than many teams give it.

Grouping makes aggregators more powerful

Make's docs also note that an aggregator can split output into separate groups using the Group by field.

That lets one aggregation step produce:

• one bundle per customer
• one bundle per file type
• one bundle per category
• one bundle per distinct grouping key

That is a strong pattern when the business logic needs grouped results rather than one giant combined output.

The best design question is: should the next module receive many bundles or one?

This question usually resolves the confusion quickly.

If the next step should process each item separately, use an iterator.

If the next step should receive one structured result, use an aggregator.

That framing is often more useful than memorizing module names.

Common mistakes

Mistake 1: Using an iterator when the next module really needs a combined result

That creates unnecessary downstream complexity.

Mistake 2: Aggregating too early

Once you aggregate, individual item-level data is no longer naturally flowing through the scenario.

Mistake 3: Forgetting to include needed fields in the aggregator setup

This is one of the most common causes of missing downstream context.

Mistake 4: Treating arrays and bundles as interchangeable

In Make, they are not the same thing.

Mistake 5: Ignoring grouping opportunities

Sometimes the cleanest output is not one final bundle, but one grouped bundle per key.

Final checklist

Before choosing an iterator or aggregator in Make, ask:

1. Is the incoming data an array inside one bundle?
2. Does each item need to be processed separately?
3. Should the next module receive many bundles or one combined result?
4. Will any fields need to survive past the aggregation step?
5. Do the results need to be grouped by a key?
6. Are you changing data shape intentionally or just trying to make the scenario work?

If those answers are clear, the right module choice is usually obvious.

FAQ

What does an iterator do in Make?

An iterator converts an array into separate bundles so each item can be handled one at a time in the rest of the scenario.

What does an aggregator do in Make?

An aggregator accumulates multiple bundles and outputs a single bundle, usually with an array containing the collected data.

When should a team use both together?

Teams often use both when they need to split an array, process each item individually, and then combine the results back into one bundle for a downstream action.

What is the biggest iterator or aggregator mistake?

A common mistake is losing needed fields after aggregation because those fields were never included in the aggregator's configuration.

Final thoughts

Iterators and aggregators are not competing tools.

They are complementary shape-changing tools.

The best scenarios use each one at the moment the workflow truly needs the data to change form.