How Aggregators Reduce Make Operations: A Worked Guide

What an Aggregator Changes — and What It Doesn’t

An aggregator merges several bundles into a single bundle containing an array — one item per bundle it accumulated. It does not delete the original records from the external service; the source data stays exactly where it was, and the aggregator only changes the bundle shape moving through the rest of the scenario.

What it changes is how many bundles reach the modules positioned after it. Ten separate bundles become one combined bundle, so a downstream action that used to run ten times can, in the right circumstances, run once instead.

What it doesn’t change is any operation that already happened before the aggregation point. If modules already processed each of ten bundles individually before the aggregator, those operations already occurred and can’t be reduced retroactively — only the operations after the aggregation boundary are affected. The aggregator also doesn’t change per-operation credit rules for other features; dynamic-credit modules, such as some built-in AI apps or Make Code, keep their own documented cost regardless of where they sit relative to an aggregator.

Source Module, Aggregation Boundary, and Bundles

Every aggregator module is configured with a source module — the point in the route from which bundle aggregation begins. The source module is usually an iterator or a search module that outputs a series of bundles. Once the source module is set and the aggregator’s setup is closed, Make wraps the route between the source module and the aggregator in a shaded area to show where aggregation starts and ends.

Bundles output from the source module, and from any modules positioned between the source module and the aggregator, are the aggregator’s input bundles. The aggregator accumulates them during a single source module’s operation and outputs one bundle with an array — one item per accumulated bundle — as its output bundle. That single output bundle, not the individual inputs, is what continues to the rest of the route.

For the broader mechanics of how bundle counts multiply operations before you ever reach an aggregator, see MetaFlowKit’s guide to how Make operations work and why bundles multiply usage; this article focuses specifically on the reduction side of that relationship, and on iterator behavior only to the extent it establishes the aggregator’s input, covered in more depth in MetaFlowKit’s Make platform hub.

Official Worked Example: 11 Operations Versus 3

Make’s Operations guide gives this before-and-after optimization example. A trigger returns ten bundles and a single per-bundle action processes each one individually.

The reduction works because the aggregator changed how many bundles reached the action module — from ten down to one. It does not erase the trigger’s operation or the aggregator’s own operation; those still happened. Treat both totals as the documented simple model, not a guarantee for every scenario shape — multiple source operations, cycles, routes, or grouping can produce more than one aggregation within a single run.

A Reusable Estimate: Four Zones to Count

A single before/after comparison isn’t enough for a real scenario, since work often happens both before and after the aggregation boundary. A more complete estimate separates four zones:

• Upstream operations — everything before the source module, including the trigger.
• In-boundary operations — any modules between the source module and the aggregator that already ran once per bundle.
• Aggregation operations — one operation per aggregation the aggregator performs, which can exceed one if routes, cycles, or multiple source runs create more than a single aggregation in the run.
• Downstream operations — modules after the aggregator, which now run once per aggregator output bundle rather than once per original bundle.

Add the four zones together for a pre-run estimate, then confirm the real total in scenario history, since grouping and empty-aggregation settings both change the downstream bundle count in ways a static formula can’t fully predict on its own.

Group By: Why Distinct Groups Can Multiply Downstream Runs

The aggregator’s Group by field changes the simple one-bundle-in, one-bundle-out picture. Group by accepts a formula that’s evaluated for each input bundle, and the aggregator then outputs one bundle per distinct value that formula produces. Each output bundle contains a key item — the distinct value — and an array item holding the aggregated data for that key.

This means a grouped aggregation does not collapse everything into a single downstream bundle. If ten contacts group into three distinct values, three bundles reach the next module, and that module runs three times — not once. Don’t assume a grouped aggregator behaves like the ungrouped before/after model above; recalculate the downstream operation count using the number of distinct groups your data actually produces, and verify it in scenario history rather than assuming it in advance.

Empty Aggregation and “Stop Processing After an Empty Aggregation”

By default, an aggregator outputs an aggregation result even when no bundles reached it — for example, because every candidate bundle was filtered out upstream. That default-case output bundle still continues to the rest of the route.

Enabling Stop processing after an empty aggregation changes this: with the option on, the aggregator produces no output bundle when nothing reached it, and the flow stops at that point. This affects both the expected downstream bundle count and whatever notification or fallback logic depends on the flow continuing.

Check which behavior your scenario needs before assuming either one. A workflow that should send a summary email only when there’s something to summarize needs the “stop” option enabled; a workflow that should log a zero-record status regardless needs the default behavior.

Field-Mapping and Data-Loss Risks Across the Boundary

Fields from the source bundles, and from any modules inside the aggregation boundary, are not automatically available after the aggregator. Only what you explicitly include in the aggregator’s setup — for example, the aggregated fields configuration of the array aggregator module — survives into the output bundle’s array. Bundles output from the source module and any modules between the source module and the aggregator are not themselves output by the aggregator, so their items aren’t accessible later unless mapped in.

This creates a common data-loss pattern: a builder maps three fields into the aggregated output, later realizes a fourth field — a record ID, a timestamp — is needed downstream, and has to return to the aggregator’s field mapping rather than assuming it carried through automatically. Before treating an aggregation as final, confirm every field a later module will need is explicitly mapped in the aggregator’s own setup, not just present somewhere earlier in the route.

Safe Optimization Sequence

1. Confirm the required outcome first — does the business actually need one combined result, or separate per-record results that happen to look similar?
2. Count the current flow’s operations using scenario history before changing anything, so you have a real baseline instead of an assumed one.
3. Move the aggregation boundary only when the combined result is genuinely correct for the destination and the requirement — not purely to reduce a credit total.
4. Verify the output shape: check that grouped or ungrouped aggregation produces the bundle count and field set the next module actually needs.
5. Test with synthetic data that includes edge cases — an empty input set, a single input bundle, and a large batch — before pointing the change at production data.
6. Compare the actual post-change operation count in scenario history against your baseline from step two.
7. Retain a rollback path: keep the pre-aggregation route available or documented until the new design has run successfully across a normal usage cycle.

Verify Before You Publish the Change

• Open scenario history for both the old and new route and compare actual operation counts, not just the estimate from the four-zone model above.
• Expand the aggregator’s white bubble and confirm the accumulated bundle count matches what you expected from the source module.
• If Group by is set, confirm the number of output bundles equals the number of distinct group values in real data, not one.
• Confirm every field the next module needs is present in the aggregator’s output bundle, not just visible somewhere earlier in the route.
• Re-check behavior with an empty input set to confirm the “Stop processing after an empty aggregation” setting matches what the workflow actually needs.

What Aggregators Do Not Solve

An aggregator changes bundle shape and flow. It does not, by itself, guarantee ordering, transactional safety, deduplication, or idempotency for the records it combines.

If a workflow depends on retries without duplication, on strict ordering, or on transactional all-or-nothing behavior, that reliability needs to come from the destination’s own API contract, from error handlers, or from application-level deduplication — not from the presence of an aggregator in the route. Use MetaFlowKit’s automation usage calculator to model the operation counts once you’ve separately confirmed the reliability requirements are met.

Frequently Asked Questions

Does adding an aggregator always reduce total operations?

No. It reduces operations only when the aggregation genuinely lowers the number of bundles reaching later modules and doesn’t add extra aggregations through grouping, routes, or multiple cycles. Verify the before-and-after counts in scenario history rather than assuming a reduction.

Does the aggregator delete the original source records?

No. Aggregation only changes the bundle shape moving through the rest of the Make scenario; it doesn’t modify or remove the underlying data in the external service.

What’s the difference between the aggregator’s source module and the scenario’s trigger?

The trigger starts the scenario. The source module is a separate, aggregator-specific setting that marks where bundle accumulation for that particular aggregator begins — it’s often an iterator or search module positioned after the trigger, not the trigger itself.

Does Group by ever produce just one output bundle?

Only if every input bundle evaluates to the same group value. Otherwise, the aggregator outputs one bundle per distinct value, so downstream modules can still run multiple times.

Does an aggregator guarantee data arrives at the destination in order?

No. Aggregation changes bundle shape and count; it does not add ordering guarantees, retry logic, or deduplication. Those requirements need separate verification with the destination service.