How to Add and Configure Aggregators in Make.com

What a Make.com aggregator does

A Make.com scenario can produce several bundles from a search, iterator, webhook payload, or another module that returns multiple items. Without an aggregator, downstream modules normally process those bundles one at a time. An aggregator collects selected values from those bundles and presents them together as one output bundle.

For example, a search module might return ten open tasks. A following email module would typically run once for each task. An array aggregator can collect the task details so that one later module can build a single digest. The result is not necessarily fewer operations in every scenario, but it can give the workflow a clear point at which repeated records become one business message, document, or update.

When should you use an aggregator?

Use an aggregator when several related bundles need to be consumed as one logical unit. Common examples include:

• Collecting order lines before creating one order summary.
• Combining search results into one email, chat message, or report.
• Building an array for a database, API, document, or custom application.
• Joining repeated events that belong to one customer, project, ticket, or reporting period.
• Collecting values before passing them to a module that expects a list rather than individual records.

Do not add an aggregator simply because a previous module returned multiple items. If every item should trigger its own notification, record update, or approval, processing the bundles individually may be the correct design.

Understand the difference between iterators, routers, and aggregators

These Make.com tools solve different problems and should not be treated as interchangeable:

A router is different again. It creates multiple routes so bundles can follow different logic. A router does not, by itself, combine those routes into one result. If a scenario first splits a collection with an iterator and later needs to produce one summary, an aggregator may be used after the item-level processing. The exact placement depends on the route and the required business state.

Prepare the scenario before adding an aggregator

A reliable aggregator starts with a defined input and output. Review the scenario in this order:

1. Identify the repeated source. Find the module that produces multiple bundles during a run. This may be a search, webhook, iterator, or another module with repeated output.
2. Define the group boundary. Decide whether all bundles belong together or whether they should be separated by a customer, order, date, project, or another key.
3. Define the downstream action. Specify what the next module should do with the grouped result.
4. Select the fields that matter. Keep the identifiers and values required for the downstream decision. Avoid collecting every available field without a purpose.
5. Decide how empty input should behave. Consider whether the scenario should skip the next action, send an empty result, or follow an alternative route when no bundles match.

This preparation prevents a common failure mode: an aggregator that technically works but produces a result that nobody can interpret or use.

How to add an aggregator in Make.com

1. Open the scenario and locate the repeated output

Open the Make.com scenario and identify the point where multiple bundles are produced. Run the relevant part of the scenario if necessary and inspect the execution data. Confirm that the bundles contain the records you expect before changing the scenario structure.

2. Insert the aggregator on the correct path

Add the aggregator after the module whose bundles you want to collect and before the module that should consume the grouped result. In the scenario editor, use the insertion control on the connection line, search for the required aggregator type, and select it.

Placement matters. If the aggregator is placed before a filter, the filter may no longer operate on individual records in the way you intended. If it is placed on only one router route, it will collect the bundles that reach that route, not necessarily every bundle produced elsewhere in the scenario.

3. Select the source module

Open the aggregator settings and choose the source module whose bundles should be collected. The source should normally be the module that creates the repeated output, not simply the module immediately before the aggregator if the scenario contains branches or other processing.

Inspect the available source fields and confirm that they belong to the records you want to group. If the wrong source is selected, the aggregator can appear configured while returning empty or unrelated values.

4. Choose the aggregator type

The most common choices are an array aggregator and a text aggregator:

• Array aggregator: Creates a collection of structured items. Use it when the next module needs separate fields such as an ID, name, amount, status, or date for each record.
• Text aggregator: Combines selected values into one text output. Use it for readable lists, message bodies, notes, or simple summaries where the downstream module needs text rather than structured records.

The right choice depends on the receiving module. If a later API or database operation needs to address each item, preserve structured fields with an array. If a person will read the result in an email or chat message, a text result may be more practical.

5. Map the fields and define formatting

Map only the fields that the next step needs. For an array, this may include a record ID, title, owner, status, amount, and URL. For a text aggregator, define the values that should appear in each line and use a clear separator or line format.

Think about missing values, date formats, numeric precision, and the order in which records should appear. If the order affects interpretation, make it explicit before aggregation or in the aggregator configuration where supported. Do not rely on an incidental execution order unless that order is acceptable for the business process.

6. Configure grouping and limits carefully

Some aggregation designs require a grouping value so that related bundles remain together. For example, records may need to be grouped by customer ID rather than combined into one collection for the entire scenario run. If a grouping field is required, use a stable business identifier rather than a display name that may change or be duplicated.

Also review any item limits, filters, or scenario settings that could restrict the input. A technically valid output can still be incomplete if records were filtered out earlier or if the collection is larger than the downstream system can handle reliably.

Map the aggregated output into the next module

After the aggregator runs, the next module should receive one bundle containing the aggregated result. An array aggregator usually exposes a collection of items. A text aggregator exposes combined text. The exact field names depend on the module and configuration, so use the execution inspector to confirm the output rather than assuming a field name.

For an email or chat digest, map the text result into the message body. For a document or database operation, map the array into the field that expects a list. For an API request, check whether the receiving endpoint expects an array, an object containing an array, or formatted text.

Test and troubleshoot the aggregator

Test the scenario with representative data, including more than one input bundle. A single test item cannot confirm whether aggregation is working correctly.

1. Run the scenario once with known sample data.
2. Open the source module and confirm how many bundles it produced.
3. Inspect the aggregator output and verify that the expected items and fields are present.
4. Check whether the output is an array, text value, or another structure required by the next module.
5. Inspect the downstream module to confirm that it runs once at the intended point.

If the output is empty, verify the selected source module, filters, route placement, and field mappings. If some records are missing, check whether they were excluded before the aggregator or whether grouping logic separated them. If the next module receives repeated actions instead of one action, inspect whether it is mapped to the original repeated bundle rather than the aggregator output.

Operational design rules for Make.com aggregators

Represent a business state, not just a technical step

Name the aggregator after the result it creates, such as “Collect open tasks for weekly digest” or “Build order lines for invoice request.” Clear names make the scenario easier to maintain because they explain why the aggregation exists.

Keep ownership visible

Decide who owns the grouped output and the action that follows it. If an aggregator creates a customer summary, someone should own the review, delivery, or exception handling associated with that summary. A collection without an owner can become a silent queue of unprocessed information.

Protect data quality before aggregation

Aggregation can hide bad records inside a larger collection. Validate required identifiers, remove irrelevant items, and apply the right filters before grouping. It is usually easier to diagnose one invalid bundle before aggregation than to find it inside a large array later.

Design for the receiving system

Large collections can create payload, readability, or processing problems. Where appropriate, split the work by a meaningful business boundary such as customer, reporting period, or order. Do not assume that combining data is always more efficient. The best design is the one that gives the next decision-maker or system the right amount of information in a usable form.

Example: creating one customer activity digest

Consider a hypothetical scenario that searches for recent customer activities and returns one bundle per activity. The requirement is to send one internal digest per customer, not one message per activity.

The scenario could filter out activities without a customer identifier, group the remaining records by customer, and use an array or text aggregator for each group. The output would then be passed to a message module that creates one digest containing the activity title, date, owner, and link. The important design decisions are the customer identifier used for grouping, the fields included in the digest, and the owner responsible for reviewing exceptions.

If the requirement changes to update each activity individually, the aggregator should be removed from that path. This example illustrates why the business action should be defined before the module is added.

Make.com aggregators in a wider automation design

An aggregator is one component in a broader workflow. It should sit inside a process with clear input conditions, ownership, exception handling, and reporting. If the scenario is becoming difficult to reason about, adding more modules may not solve the underlying problem. A clearer data model, better naming, or a defined handoff may be more valuable.

For broader workflow architecture and implementation support, see ConsultEvo’s systems and automation services. You can also review examples of connected operations, CRM, and automation systems for context on how individual workflow steps fit into larger operating processes.

Use an aggregator when repeated records genuinely need to become one meaningful business input. Define the grouping logic first, configure the module second, and test the complete handoff rather than treating aggregation as an isolated technical trick.