The Aggregator in Make.com collects multiple bundles from an earlier module and turns them into one output bundle containing an array. This lets a scenario treat a group of records as one business operation instead of sending each record through the next module separately.
The important design question is not simply how to add an Aggregator. It is what the batch represents, when the batch should be released, and what the next module is expected to do with the result. A well-designed Aggregator can support digest emails, bulk updates, grouped reports, and controlled API requests. An unclear aggregation boundary can produce incomplete batches, oversized payloads, or data that is difficult to reconcile.
Use the Aggregator when the downstream action makes more sense for a collection of items. If every item needs its own independent action, process the bundles individually or use an Iterator later only when there is a clear reason to fan the data back out.
What the Aggregator does in Make.com
Make.com scenarios pass data between modules as bundles. A bundle might represent one CRM record, one order, one webhook event, or one result returned by a search module. The Aggregator receives multiple bundles and creates a single bundle with an array of mapped items.
The output changes the shape of the data. Before aggregation, the next module may run once for every incoming bundle. After aggregation, the next module receives one grouped result. Each element in the array can contain the fields you selected from the source bundles, such as an ID, name, status, amount, or timestamp.
An Aggregator is a batching decision, not just a formatting step. The batch should correspond to a meaningful unit of work for the module that follows it.
For example, a daily report may need one array containing all records returned during a scenario run. A bulk API endpoint may need a list of items in one request. In contrast, sending a separate notification to each account owner usually does not benefit from aggregation unless the notification itself is designed as a digest.
How aggregation affects scenario execution
The Aggregator sits after a source or processing module and collects the bundles that reach it during that execution path. It then produces an aggregated output when the source stream reaches the configured boundary, such as the end of the available input or a configured collection limit where supported.
- Bundles are produced: A preceding search, webhook, database, or application module returns one or more bundles.
- The Aggregator collects them: Each incoming bundle contributes one item to the aggregated array according to the fields you map.
- The collection ends: Make.com releases the aggregated result when the relevant source processing or configured limit ends.
- The next module runs: The downstream module receives the grouped bundle and can process the array as a whole.
This means an Aggregator does not automatically create a permanent queue or wait indefinitely for future scenario runs. It operates within the execution flow where it is placed. If records arrive in separate scenario runs, they will not necessarily be combined unless the scenario stores them somewhere and retrieves them as a later collection.
Always define the aggregation boundary in business terms. Ask whether the batch means one scenario run, one customer, one reporting period, one API request, or one operational handoff.
When to use an Aggregator
Aggregation is useful when the next step is more efficient or more understandable with a collection of items. Common patterns include:
- Summary communications: Collect new tasks, transactions, or activity records and place them into one email or message.
- Bulk updates: Build a list for an API or application module that accepts multiple records in one request.
- Grouped reporting: Combine records before writing a structured report to a document, spreadsheet, or database.
- Payload construction: Create a nested array that matches the structure required by a downstream service.
- Controlled handoffs: Pass a defined set of records to another process instead of triggering a separate handoff for every item.
Do not use an Aggregator merely because the output contains several records. If the receiving module expects one record at a time, aggregation can add complexity without improving the process. A useful diagnostic question is: What decision or action becomes possible only after these items are considered together?
How to configure the Make.com Aggregator
1. Identify the source module
Add the Aggregator after the module that produces the bundles you want to collect. The source might be a search module, a webhook processing step, a database query, or another application module. Select the correct source in the Aggregator configuration so Make.com knows which bundles belong to the collection.
Do not choose the source based only on its position in the scenario. Choose the module that represents the start of the data set you want to group. If filters or routers change which records reach the Aggregator, test those paths separately.
2. Define the item structure
Use the Aggregator mapping fields to decide what each array item should contain. Include the minimum fields required by the next step. A compact structure is easier to inspect, transfer, and maintain than an item containing every available field.
For example, a report item might contain an order ID, customer name, total, and status. A bulk update item might contain only the record ID and the fields that need to change. Use consistent field names and data types so downstream mapping does not depend on accidental differences between source bundles.
3. Decide whether grouping is required
If all incoming items belong in one collection, a single aggregated array may be sufficient. If the output must contain separate collections, use a grouping value where the module and scenario design support it. A grouping key could represent a customer, project, owner, region, or reporting period.
Grouping is not the same as filtering. Filtering decides which records continue. Grouping decides which records belong together in the output. Keep those responsibilities separate so the scenario is easier to reason about.
4. Set a safe collection boundary
Make sure the collection has a predictable end. Depending on the scenario, that may be the end of the source module’s results, a supported maximum item limit, or another explicit control in the design. Avoid assuming that an Aggregator will solve volume management automatically.
Large arrays can create oversized payloads, slower processing, or downstream application limits. If the source can return many records, consider narrowing the query, processing smaller batches, or storing records before a separate scheduled collection step.
- What does one aggregated item represent?
- What business event ends the collection?
- Which fields are actually required downstream?
- What should happen when no bundles reach the Aggregator?
- What is the maximum practical array size for the receiving module?
- How will you identify the source records if a later step fails?
Mapping the aggregated output
After the Aggregator runs, inspect its output bundle in the scenario execution history. You should see an array containing the mapped items. The next module must be able to accept that array in the format you provide.
There are two common paths:
Process the array as one unit
Use this when the receiving module supports a list or when the purpose is to send one report, one document, or one bulk request. The batch remains intact and the downstream action runs once.
Process items individually
Use an Iterator after the Aggregator when a later action requires one item at a time. This can be useful for a deliberate second stage, but it may remove the efficiency gained by batching if used without a clear reason.
Mapping errors often occur when users expect an array field to behave like a single text value, or when a downstream module expects a different object structure. Inspect the sample output, map the array at the correct level, and test with more than one source bundle.
Example: creating a daily activity digest
Consider a hypothetical operations team that wants one daily message containing newly created tasks. A search module retrieves the tasks, a filter excludes records that are already reported, and an Array aggregator creates items containing the task ID, title, owner, and due date. The messaging module then receives the array and formats one digest.
The important design choice is that the digest is the business unit of work. The team does not need one message per task. The scenario should also define what happens when the search returns no matching records. It may skip the message, send an explicit empty-state notice, or record the run for monitoring.
If the digest fails, the task IDs in each item provide a basis for retry and reconciliation. Without stable identifiers, it becomes harder to determine whether a later run will duplicate, omit, or resend records.
Example: batching an external update
Suppose a hypothetical finance process finds several approved records that must be sent to an external system. The Aggregator builds an array containing the external reference, amount, currency, and approval timestamp. One downstream request sends the batch if the external service supports that payload.
The scenario still needs a response-handling plan. A successful request should identify which records were accepted. A failed request should preserve enough information to retry safely. If the external system has a payload limit, the collection must be split into controlled batches rather than allowing one run to create an unbounded request.
Batching reduces repeated work only when the batch boundary, payload limit, and failure path are all explicit.
Common Aggregator mistakes
Aggregating before defining the business state
Grouping records does not decide whether they are ready for processing. Apply the relevant status, date, ownership, or approval logic before aggregation. Otherwise, the batch may mix records that require different actions.
Assuming every run has the same number of bundles
Search results and webhook traffic can vary. Test the scenario with zero, one, several, and many bundles. The downstream modules should behave intentionally in each case.
Sending more data than the next module needs
Unnecessary fields make payloads harder to inspect and can expose data that the next process does not need. Define a useful item schema rather than copying the entire source object by default.
Using an Iterator without a reason
An Iterator turns array items back into separate bundles. That is useful when the next operation is inherently item-level, but it can recreate the original per-record processing pattern and increase operations or external calls.
Ignoring ownership and reconciliation
A batch should have a clear owner and a way to trace its items. Include stable record IDs, preserve relevant timestamps, and decide where processing status is recorded. This turns aggregation into a manageable operational step rather than an opaque data transformation.
A practical decision sequence
A strong Make.com scenario is not defined by how many modules it contains. It is defined by whether the data shape, ownership, decision logic, and exception path are clear. The Aggregator is valuable when it represents a real operational handoff. If the process is unclear, adding more batching or more modules will not make the automation reliable.
For wider workflow design, review automation and integration consulting or systems, CRM, and automation implementation services. For an example of connected operational data, see the commerce and operations intelligence platform portfolio page.
Frequently asked questions
What does the Aggregator do in Make.com?
The Aggregator collects multiple bundles from an earlier module and outputs one bundle containing an array of mapped items. This allows a later module to process the collection as one operation.
When should I use an Array aggregator in Make.com?
Use an Array aggregator when the downstream action needs a list, such as a digest, grouped report, bulk request, or structured payload. Do not use it simply because several records exist if each record still requires an independent action.
Can I process aggregated items individually?
Yes. You can place an Iterator after the Aggregator to turn array items back into separate bundles. Use this only when a later step genuinely requires item-level processing.
How do I prevent an Aggregator from creating oversized batches?
Limit the source data, define a practical collection boundary, use supported batch limits, and consider processing records in smaller groups. Test the receiving system's payload and processing constraints.
What should I test in an Aggregator scenario?
Test zero, one, several, and many source bundles. Check the array structure, empty-result behavior, downstream mapping, stable record identifiers, and the recovery path if the batch action fails.
Design more reliable Make.com workflows
If your scenario has unclear batch boundaries, fragile handoffs, or difficult-to-maintain mappings, ConsultEvo can help clarify the process and design the automation around a reliable operating model.
