Iterator and Aggregator in Make: arrays, bundles and summary outputs

Define the order and item units

Use fictional order O-101 with an items array containing SKU A with quantity 2 and SKU B with quantity 1. The goal is to check each line and create one order result. Decide whether each line also needs a ledger write or merely contributes to a summary. Those choices change downstream work even though the input order is the same.

Inspect the previous output before adding an Iterator

An Iterator turns an array into separate bundles, one for each item. A search module may already return separate bundles; adding an Iterator then may be unnecessary. In an isolated scenario, inspect the previous output to distinguish one bundle containing an array from a sequence of individual bundles. Do not infer the structure from how the source displays a table.

Map the array and preserve its context

Map the preceding items array into the Iterator’s Array field. Use item-level SKU and quantity downstream, and associate results with the order ID. If fields are missing from mapping suggestions, inspect the source JSON or webhook data structure and obtain a safe practice output. There is no reason to use genuine customer details merely to teach an example structure.

Choose where aggregation begins

Set the Array aggregator’s Source Module to the module whose output starts the aggregation range. Include the processing needed to create your desired item results. Aggregation combines received bundles within its source operation; it does not restore filtered-out items or automatically gather results from unrelated scenario executions. Check the highlighted range rather than choosing a module by its visual proximity.

Include fields needed after the aggregation

Fields from modules inside the aggregation range do not all remain available afterward. Include order_id, SKU, quantity and result in the aggregated output when later steps need them. If separate order summaries are required, consider grouping by order_id. If a single cross-order digest is the goal, check that grouping into individual orders still serves that output design.

Decide what an empty result means

An order with no items differs from an order whose items were all filtered out. Review Stop processing after an empty aggregation to determine whether an empty result proceeds downstream. Decide whether to emit “no matching items,” omit the message or create a review record. A blank array should not silently become proof that every business check was completed.

Check counts and usage with several inputs

Use fictional cases with one item, several items, an empty array, a repeated order ID and two different orders. Count item-level effects separately from order-level messages. Inspect execution details for the actual module work as input grows. This guide provides acceptance cases rather than measured credits or performance results from connected accounts.

Keep durable state and duplicate prevention separate

A new execution of the same order can still produce another message after aggregation. Maintain appropriate order or item processing keys separately. For a report spanning a week, store records in a ledger and query a defined reporting period. An Aggregator is useful within a flow; it is not a replacement for that period-based record store.

• Create a report for a defined week
• Prevent repeated order effects
• Investigate unexpected usage growth