---
title: "Notifications"
id: "2154"
type: "page"
slug: "notifications"
published_at: "2026-10-04T08:29:34+00:00"
modified_at: "2026-10-22T16:38:23+00:00"
url: "https://xedant.com/agents/crm/addons/notifications/"
markdown_url: "https://xedant.com/agents/crm/addons/notifications.md"
excerpt: "The add-on Notifications is the CRM’s bell. It makes sure the right event reaches the…"
---

# Notifications

[https://xedant.com/agents/crm/addons/notifications/.md](https://xedant.com/agents/crm/addons/notifications/.md)

The add-on **Notifications** is the CRM’s bell. It makes sure the right event reaches the right person — a new lead, an approaching deadline, a customer’s reply, a mention in a dialogue — without turning the working day into a stream of pop-ups. Everyone chooses what to be told about and can receive one digest letter a day.

![Notifications add-on: the bell panel with no unread rows and the note about when rows land there](https://xedant.com/wp-content/uploads/2026/10/crm-agent-addon-notifications.png)## Why you need it

When there are many events, a team stops noticing them. A deadline passes because nobody saw it in advance, a customer waits for a reply because the letter reached the wrong colleague, and a new lead sits untouched until the manager happens to look.

Notifications fix this quietly. Events do not scatter as pop-ups that get dismissed unread: they land in one list per person, and the list stays where it is when the page reloads, because it is data. Settings per event type let each person switch off what does not concern them and keep what they are really needed for.

## What it does

- **Every producer reaches one place.** All parts of the product publish events through one port, and Notifications decides who sees them — the assignee of a lead, the owner of a deal, the colleague a ticket belongs to. Nobody has to check five screens; the bell is enough.
- **Typed rows, not toasts.** Each event lands as a typed per-user row carrying the event’s payload, a deep link to the place it happened and its own limited lifetime. Nothing marks itself read, and the list survives a reload because it is stored data, not a fleeting hint.
- **Your own settings, per event type.** On the Notification settings screen each type has its own seats: show in the app, include in the daily digest letter, or mute the type entirely — a muted type produces neither rows nor digest lines.
- **A personal inbox, not a shared one.** The own-inbox surface reads with the personal login and covers read, mark-read, clear and preferences. The management key is refused by name on every “me” route, so another person’s list cannot be pulled up with it.
- **One digest letter a day.** A single system letter goes out over the unread rows of the types a person seated for the digest. It is an internal notice to an employee over the workspace’s SMTP settings — never the marketing rail — and only a letter that actually went out stamps its rows.
- **Marking, not deleting.** “Mark all read” and per-row marking only flip a flag; nothing is removed. And the product never marks a row read by itself: read means the person truly opened it.
- **Links that lead to a real place.** A row points straight at the deal, ticket or dialogue it came from. The address is set only under allowlisted schemes — anything else stays plain text, so the bell never sends an employee to an unfamiliar destination.
- **One row per event key.** Each dispatch carries its own key, so a redelivered event or a re-run pass adds nothing: the list keeps exactly one copy of the fact.
- **Safe to switch off.** Every producer calls the core port, so with Notifications inactive nothing else is affected — events still happen and journal; there is simply no separate list and no settings.

## How it relates to other add-ons

Notifications declares no required add-ons and installs on its own. Other contours lean on it rather than the other way round: reminders from [Calendar](/agents/crm/addons/calendar)
 are delivered through this port, and rules from [Automation](/agents/crm/addons/automation)
 dispatch through the same shipped port and the same preference centre, so a recipient’s settings are honoured by construction, never bypassed. Switching Notifications off breaks neither: reminders still journal and rules still run — there is simply no bell.

## Honest limits

- The bell has no external channels: no SMS, no messengers, no push to a phone. Everything lives inside the app and in the system digest letter; customer messages over messengers belong to other add-ons, not to notifications.
- The digest letter is an internal notice to an employee, not a marketing send. This contour never touches the marketing rail and cannot be used to replace a campaign.
- Rows live for thirty days, then the retention sweep removes them. There is no archive: if a notification has to be kept, it belongs in a task or a note on the record.
- Nothing is marked read automatically, not even a row you actually opened — it waits for your mark. That is deliberate, so the list reflects what a person really saw.
- Someone else’s inbox cannot be read, not even with the management key. Notifications are a personal matter, and no setting changes that.
- A deep link obeys the allowlist. If the scheme is not allowed, the row stays text with no way to click through.
- A muted type produces no rows and no digest lines: if “in the app” is off for a type, there is simply nothing to put in the letter.
- The digest goes out once a day. A forced run made before anything new stands sends nothing and does not repeat yesterday’s letter.

All add-ons → [Add-ons catalogue](/agents/crm/addons)

[← CRM Agent documentation](/agents/crm/docs)