Centralizing multi-tool notifications into a single AI digest with n8n

An SMB using n8n to automate its customer relationship quickly ends up with notifications coming from everywhere: an AI-prioritized email, a Sentry alert, a support ticket flagged urgent, a new CRM lead to qualify, a GitHub comment. Each alerting system is reasonable in isolation. Added together, they reconstruct exactly the problem automation was supposed to solve: attention fragmented into dozens of interruptions a day. This guide builds a single AI digest in n8n that absorbs these heterogeneous streams and only surfaces what genuinely deserves an interruption.

Why group sources instead of triaging them one by one

Our guides on AI email triage and AI support ticket scoring each show how to prioritize one source. The problem shows up once you stack several of these digests: an email digest at 8am, a ticket digest at 9am, a Sentry summary at 10am. You've replaced continuous noise with scheduled noise, without actually reducing the number of interruptions.

The cost of these interruptions is well documented. A study by Mark, Gudith and Klocke presented at CHI 2008 (The Cost of Interrupted Work: More Speed and Stress) measured, with real office workers, that resuming a task after an interruption pushes people to work faster to compensate — at the cost of measurably higher stress and frustration (see the study on Google Scholar). Along similar lines, a 2015 study by Kushlev and Dunn published in Computers in Human Behavior found, in a real-world protocol, that limiting email checking to three times a day significantly reduces daily stress compared to unlimited checking (see the study on Google Scholar). The practical takeaway is the same in both cases: it isn't the volume of information that costs you, it's how fragmented it is across time. A single digest, at a fixed time, applies that principle to all your alert sources at once — not just email.

The architecture: a four-stage pipeline

1. Collection: each source (email, Slack, ticket, CRM webhook, RSS feed) triggers its own small workflow, whose only job is to normalize the event and push it onto a shared queue.
2. Normalization: every event is reduced to the same schema, regardless of origin.
3. Daily aggregation: a Schedule Trigger reads the whole queue once a day and hands the full batch to an LLM.
4. Synthesis and delivery: the model produces a single structured note, sorted by priority, sent to the channel of your choice.

Stage 1 — Normalize every source into a shared schema

This is the step that decides whether the final digest is readable or unreadable. It doesn't matter whether the event comes from an email, a Zendesk ticket, or a Sentry alert (see our guide to AI-triaged Sentry alerts): an Edit Fields (Set) node placed right after each trigger converts it to the same minimal structure:

{
  "source": "email | slack | ticket | crm | github",
  "title": "short summary of the event",
  "content": "raw text, truncated to 1000 characters",
  "url": "direct link to the original item",
  "timestamp": "2026-08-02T09:14:00Z",
  "declared_urgent": true
}

The timestamp field deserves particular attention if your sources aren't in the same time zone: normalize it to UTC as soon as it enters the queue with the Luxon node (see our guide to dates and times in n8n), so an 11pm event doesn't accidentally land in the next day's digest.

Stage 2 — The queue: Data Tables or Supabase

Each normalized event is then inserted into a persistent queue with a pending status. For moderate volume — a few dozen events a day, which covers most SMBs — n8n Data Tables are more than enough: no external project to provision, a typed table with the columns above, and a Data Table node to insert each row. If you need a queryable history spanning several months, or a compliant audit trail like in the Compliance & Audit Pack (€149), a regular Supabase table remains preferable — see our n8n-Supabase connection guide.

This split between collection and processing has a second benefit: if the LLM or the delivery channel is temporarily unavailable, events simply pile up in the queue instead of being lost.

Stage 3 — Daily aggregation

A Schedule Trigger set to the time of your choosing (see our Schedule Trigger and time zones guide) triggers a read of every event still marked pending. If several collection branches feed the same queue, a Merge node in "Append" mode combines their outputs before aggregation — see our Merge node guide for the nuances of the different merge modes.

Stage 4 — LLM synthesis with structured output

This is where the real value gets created. Rather than simply listing events, the LLM receives the full batch and a prompt asking it to classify and group them, with a Structured Output Parser enforcing the shape:

{
  "type": "object",
  "properties": {
    "urgent": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "summary": { "type": "string" },
          "source": { "type": "string" },
          "suggested_action": { "type": "string" },
          "url": { "type": "string" }
        }
      }
    },
    "today": { "type": "array", "items": { "type": "object" } },
    "fyi": { "type": "array", "items": { "type": "object" } }
  },
  "required": ["urgent", "today", "fyi"]
}

On the prompt side, give explicit sorting rules rather than letting the model guess:

You receive a list of events from several tools (email, Slack, tickets, CRM, GitHub).
Classify each event into exactly one category:
- "urgent": needs action within the hour (incident, angry customer, today's deadline).
- "today": important but not blocking, handle before end of day.
- "fyi": nothing to do, just worth knowing.
For "urgent" and "today", suggest a next action in one sentence.
Merge events that are clearly about the same underlying topic into a single entry.

That last instruction — merging thematic duplicates — is what separates a real digest from a plain concatenation: three notifications about the same Sentry incident should produce exactly one line in the final summary.

Delivery and closing the loop

The structured digest is then formatted (a Code node, or a second lightweight LLM call, turns the JSON into readable Markdown) and sent by email, Slack, or Telegram. One last step, often forgotten: a Data Table node (or a Supabase query) marks each processed event as sent, so it never gets pulled back into tomorrow's digest.

Common pitfalls

• A digest that becomes its own stressful notification. If the "urgent" section lists ten items every morning, the classification threshold is miscalibrated somewhere upstream — the digest only reveals a triage problem in your source workflows, it doesn't fix it.
• No real-time safety net. The digest should never be the only channel for a genuinely blocking incident: keep an immediate alert running in parallel for anything above a severity threshold, before the event has to wait its turn in the queue.
• Cost and volume. With an economical model (gpt-4o-mini or equivalent) and a daily batch of 50 to 100 truncated events, the synthesis typically costs a few cents a day — see our AI call cost tracking guide to measure this precisely against your real volume.
• Sources that exceed rate limits. If one of your collection branches polls a high-frequency API (bursty CRM webhooks, for example), apply the practices from our guide to 429 errors before that bottleneck breaks the whole chain.

Starting from an existing base

The AI Inbox Pack (€79) already contains the core of this pipeline for the email source: AI classification with structured output and a daily Slack/Telegram digest, ready to import. Extending this base to other sources is mostly a matter of repeating the same normalization pattern for each new trigger, then converging them into a single queue and a single LLM synthesis call — a few hours of work to turn a dozen separate notification streams into a single habit: one check in the morning, and the rest of the day without interruption.