Make Iterator: map array items and verify bundle counts

SOURCE-BASED ANALYSIS · NO HANDS-ON RATING

Confirm the unit you want to process

Make's Iterator turns an array into separate bundles, one per array item. Its Array field selects the collection to split. If the mapping panel lacks item fields, Make documents running the source module or scenario with representative data so the structure becomes known. Isolate external actions while doing that discovery.

Our first recommendation is to name the business unit after every step. An order, an order line and an attachment are different units. Mapping an entire order where the next action expects one line can produce an apparently successful but incomplete integration.

An order with three lines

Assume a synthetic order ORD-DEMO-7 contains an array named lines. It holds three objects: line A with quantity 2, line B with quantity 1 and line C with quantity 4. The expected Iterator output is three line bundles, not seven bundles representing total quantity. The distinction matters when the destination creates one row per line.

For this example, each proposed destination row contains order_id, line_id and quantity. These are our schema choices. Preserve the parent order ID explicitly in the mapping so a later reviewer can reconstruct the relationship. Use order ID plus line ID as a candidate destination key only if that pair is guaranteed unique by your business contract.

Discover and map the actual structure

1. Inspect the incoming synthetic payload and locate the array, rather than selecting a similarly named text field.
2. Run only the safe source or parsing portion with representative data if item fields are not visible.
3. Select the actual array in the Iterator and inspect its output bundles.
4. Map each line's values and the parent identifier into a disposable destination.
5. Compare input line IDs with destination line IDs and verify the quantities separately.

Use a sample containing optional fields as well as required ones. A sample with only a line ID cannot establish how descriptions, discounts or nested objects should be handled. Document which optional values may be absent and which missing values must reject the record.

A compact acceptance matrix

Keep expansion separate from downstream costs

Our planning advice is to count the downstream work after expansion. If three bundles each reach two external actions, those actions receive six planned executions under that simplified design. That is workflow arithmetic, not a Make credit quote; searches, branches and retries can change the total. Use the existing credit-estimation guide for a documented allowance model.

Know when an aggregator is the next step

If the destination needs one object containing all lines, do not issue a separate order creation for each line. Design the per-line transformation first, then combine the intended results at a deliberate boundary. Verify that the final object includes the parent information the destination requires. This proposed sequence helps you inspect mappings; no account-level trial or measured performance is claimed here.