Make Iterator Operations Explained With a Worked Example

The Plain-Language Model: Bundles, Arrays, and the Iterator

A bundle is one unit of data moving through a scenario — one record, one email, one file. An array is a list stored inside a single bundle: an email’s attachments[] field, or a list module’s items[] field, is an array sitting inside one bundle, not several bundles on its own. An array item is one element of that list — one attachment, one line item, one row.

An iterator is a special type of module that converts an array into a series of bundles; each array item becomes its own separate output bundle. Before the iterator runs, five attachments arriving on one email are still one input bundle. After the iterator runs, they become five output bundles, and every module positioned after the iterator receives and processes those bundles one at a time.

This is the detail that trips up a lot of Make usage estimates: fields sitting inside an array are not operations, and they are not separate bundles, until an iterator (or a module functioning like one) actually splits them out. For the broader model of how bundle counts multiply operations across an entire scenario, see MetaFlowKit’s guide to how Make operations work and why bundles multiply usage; this article focuses specifically on the iterator’s own contribution to that multiplication.

Where the Multiplication Actually Occurs

The iterator itself is not where most of the multiplication happens, even though builders often assume otherwise. Under Make’s current documented standard module rules, an iterator uses one credit to split an array into bundles — one credit for the split action itself, not one credit per item inside the array.

The multiplication appears afterward. Once the iterator has emitted, say, five output bundles, every downstream module that receives those bundles runs once per bundle. If the next module is a standard action such as an upload or a record creation, it runs five times and uses five credits — not because the iterator multiplied anything, but because that action module processes each bundle it receives individually, the same way it would for five bundles arriving from any other source.

This distinction matters when estimating cost before you build: Make documents one credit for an iterator splitting an array, while every downstream action scales with the bundles it receives. When separate upstream bundles each contain an array, counting one split for each input bundle is a practical operational inference to verify in scenario history, not a separate universal billing formula published by Make. An aggregator placed later in the same route is one way to bring downstream scaling back down before a final action runs; that mechanism belongs to aggregation design rather than iterator behavior, so use MetaFlowKit’s automation usage calculator to model your own route’s totals once you know where the multiplication starts.

Primary Worked Model: One Email, Five Attachments

Assume a synthetic scenario: an email trigger returns one bundle containing an array field with five attachment items. An iterator splits that array. A standard upload action then receives each attachment as its own bundle.

Label this model explicitly as an estimate to verify against your own scenario history rather than a promised total, since actual attachment counts, filters, and connected apps vary from run to run.

Second Model: Multiple Upstream Bundles With Unequal Array Lengths

Real inboxes rarely deliver exactly one email per run. Assume a trigger returns two bundles in a single run — two separate emails — where the first has three attachments and the second has four.

The pattern to take from this model: total emitted bundles equal the sum of the array-item counts across every input bundle that reaches the iterator. Estimating the iterator at one split per input bundle is consistent with ordinary bundle-processing behavior, but Make’s credit guide states the simpler rule — one credit to split an array — rather than publishing this multi-input example as a universal formula. Treat the second model as an operational estimate to verify in run details.

Common Counting Mistakes

• Charging the iterator per array item, instead of per input bundle it actually processes.
• Treating fields inside an array as if each were its own operation before any module has split them out.
• Forgetting that router branches after the iterator each add their own downstream operations, on top of the iterator’s output count.
• Assuming an empty array behaves identically across every downstream module combination, instead of checking the specific modules involved.
• Confusing the number of output bundles the iterator emits with the number of operations the iterator itself used.

Safe Optimization Sequence

1. Confirm the real business requirement first: does each record need its own separate call for audit, error handling, or compliance reasons?
2. If the destination genuinely requires one action per record, don’t force batching purely to save credits — a broken audit trail costs more than a few extra operations.
3. If the destination supports an appropriate batch or bulk endpoint and per-record granularity isn’t required, aggregate the iterator’s output before the repeated action instead of after it.
4. Add a filter ahead of the iterator to remove bundles that don’t need processing; filters are documented as free of credit cost.
5. Re-run the scenario and compare the module bubbles against your pre-run estimate.
6. Record the verified counts, since real array lengths — and therefore real operation totals — can vary between runs.

How to Verify the Estimate Without Guessing

• Open the run in scenario history and expand each module’s white bubble to see its actual operation count.
• Confirm the iterator’s bubble shows a bundle count matching the array length(s) you expected.
• Confirm the downstream action’s bubble count matches the iterator’s output bundle count, not the number of fields inside any one bundle.
• In scenario history, compare the recorded Operations and Credits values for the run; do not assume they are interchangeable for dynamic-credit modules.
• Check more than one run if array lengths vary, since a single test run can understate or overstate typical usage.

Mapping-Panel Troubleshooting

Sometimes the mapping panel in a module positioned after the iterator shows only two items: total number of bundles and bundle order position, instead of the actual fields inside each array item. This happens when the iterator does not have information about the structure of the array’s items — commonly because the source module, such as JSON > Parse JSON without a defined data structure, or a Webhooks > Custom Webhook module with missing data structure, hasn’t yet told Make what fields to expect.

The documented fix is to manually execute the relevant source module so Make can learn its output structure. In the editor, you can unlink the modules after the source module to prevent the flow from proceeding further, or right-click the source module and choose “Run this module only.” Once that module has run once with real data, it learns about the items it outputs and passes that information to every following module, including the iterator and anything mapped after it.

This is a mapping-visibility issue, not a credit or operation issue — running the source module once to populate the mapping panel is a setup step, separate from the arithmetic covered elsewhere in this article.

Frequently Asked Questions

Does the iterator itself cost one credit per array item?

No. Under Make’s current documented rule, an iterator uses one credit to split an array into bundles, regardless of how many items that array contains. The per-item cost you observe afterward comes from downstream modules running once per emitted bundle, not from the iterator’s own operation count.

What happens if the array is empty?

An empty array produces no item bundles for downstream modules to process, so that branch typically shows no downstream runs. Actual billed totals for every possible module combination in this situation aren’t documented as a single universal rule, so verify the iterator’s displayed bundle and credit count in your own run details rather than assuming a fixed outcome.

Do specialized app iterators behave differently from the general Iterator module?

They exist to simplify setup — for example, selecting a source directly instead of manually mapping an array field — but their purpose is still to emit one bundle per array item, the same as the general Iterator module.

Does adding a filter before the iterator reduce credit use?

Filters are listed among Make’s documented no-credit modules, so the filter step itself doesn’t add cost. What it changes is which bundles reach the iterator: a bundle removed by the filter never produces iterator output, so the operations that would have followed it don’t happen either.

Should I iterate every record or look for a batch endpoint instead?

That depends on the destination and the business requirement, not on credits alone. If the destination offers an appropriate batch endpoint and a combined request meets the requirement, batching can reduce downstream operations. If the workflow needs one action — and one audit trail entry — per record, iterating remains the correct design even though it costs more operations.