How to Use the Make.com Array Aggregator Effectively

What the Make.com Array Aggregator does

Make.com processes data as bundles. A bundle might represent one database row, one order line, one contact, one API response, or one task. When a module produces multiple bundles, later modules normally process those bundles separately. The Array Aggregator changes that pattern by collecting bundles from a selected source module and returning one bundle containing an array.

Each element in the resulting array is built from the fields you map in the aggregator. You can preserve values from the source bundle, rename fields, combine values, or apply transformations before the data moves forward. The result can then be mapped into a single API request, email, database record, document, or other action.

This distinction prevents a common design error. If an invoice should contain ten line items, ten separate invoice operations are usually the wrong outcome. If ten records each need an independent update, aggregation may add unnecessary complexity.

Bundles, arrays, and aggregation in Make.com

Bundles are individual processing units

A bundle is one unit of data moving through a scenario. A search module may return many bundles, with each bundle representing one matching record. A following transformation module can change the contents of each bundle, but it normally does not combine them.

An array is a collection inside one bundle

An array is a field that contains multiple values or objects. After aggregation, the output is typically one bundle with an array field. The array can contain simple values, such as email addresses, or structured objects, such as product lines with an ID, description, quantity, and price.

The source module determines what is collected

The Array Aggregator is configured against a source module. This tells Make.com which module’s bundles should become array items. Modules between the source and aggregator may enrich or reshape the data, so the source should normally be the last relevant module before aggregation, not automatically the first search or trigger in the scenario.

Aggregation is also affected by scenario execution boundaries and grouping. The module does not understand your business grouping automatically. You must make sure that the bundles reaching the aggregation point belong to the same logical collection, such as one order, one customer, or one scheduled report.

When to use an Array Aggregator

The module is a good fit when one downstream action expects a collection. Common patterns include:

• Building an order payload with multiple product or service lines.
• Combining search results into one summary email or report.
• Creating one API request containing a list of records.
• Collecting transformed values before writing a single document or database record.
• Preparing a structured list for a later Iterator when another part of the process needs individual items again.

It is less suitable when every source record needs a separate action, when the receiving application accepts only one record at a time, or when the collection could grow beyond practical payload or processing limits. In those cases, process each bundle directly or use deliberate batching.

How to configure the Make.com Array Aggregator

1. Add the module at the correct point

Open the scenario and add the Array Aggregator after the module that produces the records you want to collect. If later modules enrich each record, place the aggregator after those enrichment steps so the array contains the final usable fields.

Do not place the aggregator before a filter if excluded records should not appear in the result. Likewise, do not aggregate raw records and expect a later module to make every item consistent unless that is intentional.

2. Select the source module

Choose the module whose bundles should become array items. Review the route carefully if the scenario contains routers, filters, or multiple searches. The source selection should match the actual data stream and the intended collection boundary.

3. Define the target structure

Configure the fields that each array item should contain. For example, a line item structure might include a product ID, description, quantity, and unit price. Map only fields that the receiving action needs. Clear field names and a stable structure make downstream mapping and troubleshooting easier.

When values require conversion, apply the transformation before or within the mapped field as appropriate. Check dates, numbers, empty values, and identifiers explicitly. An array can be technically valid while still being operationally wrong because a required field is blank or formatted differently from the receiving system’s expectation.

4. Use Group by when collections must remain separate

If the source contains records for several logical groups, determine how those groups should be separated. Where the module configuration provides a Group by option, use a stable key such as an order ID or customer ID. If grouping is not available or does not fit the scenario, structure the scenario so each relevant execution handles one logical group.

A grouping key should identify a meaningful business state, not merely a convenient text field. A weak key can combine unrelated records into one payload, while a missing key can produce one large array when several smaller arrays were required.

5. Map the output into the next module

The aggregator produces one output bundle containing the array. Map that array into the field expected by the next module. For an API request, confirm whether the receiving endpoint expects an array directly, an object containing an array, or a different nested structure.

If the next step needs to process each item separately, use an Iterator after aggregation. This intentionally converts the array back into individual bundles. That pattern is useful when one part of a scenario needs a consolidated payload and a later part needs item-level operations.

Practical example: building one order payload

Consider a hypothetical order workflow. A trigger identifies an order, a search retrieves its product lines, and a transformation step standardizes each line into product ID, quantity, and price. The Array Aggregator then collects those transformed bundles into a single line_items array. A final module sends one order payload to an external system.

1. The trigger establishes the order ID.
2. The search returns the order’s line-item bundles.
3. A filter removes cancelled or invalid lines.
4. A transformation step creates the required item structure.
5. The Array Aggregator builds one line_items array for that order.
6. The final action sends one request containing the order and its line items.

If the scenario instead searched across several orders at once, the order ID would become important for grouping. Without that boundary, line items from different orders could be placed in the same array. The module would have followed its configuration, but the workflow would still represent the wrong business state.

Common Array Aggregator mistakes

Aggregating too early

When aggregation happens before filtering or enrichment, the output may contain records that should have been excluded or fields that are not ready for the destination system. Prepare the bundles first, then aggregate.

Assuming one array equals one business group

Make.com can collect bundles successfully even when they represent multiple customers, orders, or reporting periods. Define the grouping rule before configuring the module.

Building an unstable item structure

Inconsistent field names, mixed data types, and optional values make downstream mapping fragile. Decide what each array item means and keep the structure consistent.

Forgetting the reverse operation

Aggregation and iteration solve opposite problems. Aggregation turns many bundles into one array-bearing bundle. An Iterator turns array items back into separate bundles. Choose between them based on the next action, not on the apparent complexity of the scenario.

Ignoring payload and operational limits

Large arrays can increase processing time, payload size, and the effect of a failed downstream request. Use filters, batching, pagination, or controlled execution boundaries when collections may grow substantially.

Validation checklist before turning on the scenario

Testing with one item can hide grouping and structure problems. Test with no matches, one match, and multiple matches when the scenario allows it. Also inspect the actual output bundle rather than relying only on the scenario diagram.

Designing better Make.com scenarios around aggregation

The Array Aggregator is one part of a broader workflow design. Start by defining the business action and the state it should create. Then decide whether that action operates on one record or a collection. Only after that should you choose aggregation, iteration, filtering, or another module.

For larger automation environments, document the source module, grouping key, target array structure, and downstream owner. This makes the scenario easier to maintain when a field changes or a receiving system introduces a new requirement. ConsultEvo’s Make.com automation service focuses on connecting workflow logic, data structure, and system ownership rather than adding modules without a clear purpose.

The same process-first approach applies when aggregation is part of a wider CRM or operations workflow. A useful automation should reduce manual work while preserving clean data, visible ownership, and reporting that supports a decision. More modules do not automatically create a better operating system. A well-defined collection boundary often matters more than a complex scenario.

For broader workflow architecture, you can also review ConsultEvo’s systems, CRM, automation and AI implementation services.