n8n Aggregate Node: Group Workflow Items Without Losing Context

The n8n Aggregate node is for the moment when a workflow has many items and the next step needs one structured payload. It can collect individual fields into lists or place all item data into a single output field.

That sounds simple, but it is a common source of broken automations. A workflow may split invoice lines, extract rows from a CSV, process support events, or loop through search results, then need one clean summary for an email, CRM note, Slack alert, database insert, or AI prompt. Aggregate is where you deliberately choose what gets grouped and what context survives.

Quick answer: what does the Aggregate node do?

The Aggregate node takes separate n8n items, or selected parts of those items, and groups them into individual output items. In practice, it turns a stream of records into a list, summary object, or grouped payload that downstream nodes can handle as one unit.

Use it after nodes that produce many items: HTTP pagination, database queries, CSV extraction, Split Out, Loop Over Items, search results, invoice line parsing, or enrichment steps. Do not use it just to hide messy data. Use it when the workflow contract really changes from many records to one payload.

Choose the aggregate type first

n8n exposes two practical ways to aggregate. Individual Fields collects specific fields from each input item. All Item Data places complete item data into one list field. The right choice depends on what the next node needs.

• Use Individual Fields when the next node needs focused lists such as order_ids, email_addresses, totals, or file_names.
• Use All Item Data when the next node needs the full records, such as all invoice lines, all extracted rows, or all search results.
• Rename fields when multiple aggregated fields would otherwise collide or become unclear.
• Keep binary data only when the downstream node actually needs files or attachments.

A reliable pattern for business workflows

Start by deciding the downstream payload shape. If a sales alert needs one message per account, aggregate line items into account_summary. If an AI step needs context, aggregate selected fields into a compact evidence list. If a database insert expects one JSON column, aggregate the complete records into rows.

The best Aggregate workflows usually have a cleanup step before the node. Normalize field names, remove fields the next step will not use, and convert missing values into predictable fallbacks. That keeps the grouped payload smaller and easier to debug.

• Before Aggregate: normalize names, types, and empty values.
• Inside Aggregate: choose Individual Fields or All Item Data deliberately.
• After Aggregate: inspect the output shape before connecting email, CRM, database, or AI nodes.
• For high-risk workflows: add a guard that blocks empty or oversized grouped payloads.

Where Aggregate fits with Split Out and Merge

Split Out and Aggregate are opposites in many workflows. Split Out turns one item with a list into many items. Aggregate turns many items back into one structured item. Merge joins branches or combines records from separate streams.

A common pattern is Split Out, enrich each item, then Aggregate the enriched results. For example, split invoice line items, look up SKU or margin data, then aggregate the enriched lines into one approval message.

Common mistakes

• Aggregating too early, before filtering bad or irrelevant records.
• Using All Item Data when a compact field list would make the downstream step cheaper and clearer.
• Dropping nulls without realizing the output list no longer lines up with another list.
• Keeping binary data by default and making the payload much heavier than needed.
• Sending a huge aggregated payload into an AI node without trimming fields first.

When to keep missing and null values

If each output list must preserve item position, keep missing and null values. This matters when you aggregate parallel fields and later assume the first email belongs to the first customer ID. If you drop nulls from one list but not another, the lists can drift.

If the downstream node only needs a clean list of available values, dropping missing values can be fine. The rule is simple: preserve nulls when position matters, remove them when only the set of present values matters.

Where Synta helps

Synta is useful when you can describe the payload contract but do not want to hand-wire every cleanup and aggregation step. Tell it what items are coming in, what the next node expects, which fields should be kept, and whether missing values should be preserved.

That lets the generated n8n workflow make the data-shape transition reviewable: clean fields, aggregate, validate output size, then send the summary to CRM, Slack, email, a database, or an AI step.

Try the Synta MCP workflow builder

If you are grouping n8n items into a clean payload, use the tracked Synta MCP path here: open Synta MCP. Describe the input items, target output shape, fields to keep, null handling, and where the grouped payload goes next.

FAQ

Is Aggregate the same as Merge?

No. Aggregate groups multiple items from one stream into a structured output. Merge combines data from separate inputs or branches. Use Aggregate for many-to-one payload shaping, and Merge for joining streams.

When should I use All Item Data?

Use All Item Data when the next step needs complete records. If the next step only needs a few fields, Individual Fields is easier to inspect and usually cheaper to pass into AI or notification nodes.

Should I include binary data?

Only include binary data when the downstream node needs files or attachments. Otherwise, leave it out so the aggregated payload stays lighter.

Why did my aggregated lists stop lining up?

One likely cause is missing or null values being removed from one field list but not another. Preserve nulls when item position matters, or aggregate complete item data instead.