Skip to content

Notifications

Keeps users on top of what changed — assignments, SLAs, escalations, approvals, mentions and more — with an in-app centre and per-user, per-category preferences. In-app is the only channel that delivers today; see Delivery channels before you plan around email, push or SMS.

  • List notifications with paging, filter by read/unread, and see an unread count.
  • Open a single notification, mark it read, mark all read, or delete one.

A bell in the app header carries the unread count and drops down the most recent notifications without leaving the page. It re-reads the count once a minute, so a new notification surfaces within about 60 seconds rather than instantly. Opening a notification from the dropdown marks it read; it also jumps straight to the record when the notification is about a case — other notification types stay put.

The centre’s Type and Priority filters and its search box do not reach the query — the API discards them, so the list does not change. Read/unread is the one filter that works.

Preferences are organised into ten categories: assignment, SLA, escalation, activity, approval, mention, comment, status, team and general. They are buckets for the preference settings below; an individual notification is not stamped with its category, so the centre cannot group or filter by one.

  • Set preferences per category for four channels — in-app, email, push and SMS — and choose an email digest cadence (instant, hourly, daily, weekly or off).
  • Update many categories at once, view the available categories, and reset preferences to defaults.

The preferences page lives at Notifications → Preferences (/notifications/preferences), reached from a button in the notification list header. It is a single grid — one row per category, a tick-box per channel, and a digest dropdown at the end. Each change saves on the spot, so there is no Save button; Reset to defaults wipes your overrides in one go. The digest dropdown stays greyed out until that category’s Email box is ticked.

Every user starts here, and every category is always returned even if it has never been touched. Push and SMS start off for every category.

Saving one box in CRM rewrites the whole row: the update fills every channel it was not told about from these defaults rather than from what you had stored. If you have customised a category, change it in one save rather than a box at a time — see Notifications & preferences.

Category In-app Email Email digest
Assignments On On Instant
SLA alerts On On Instant
Escalations On On Instant
Approvals On On Instant
Mentions On On Instant
Activities On Off Daily
Comments On Off Daily
Status changes On Off Off
Team updates On Off Off
General On Off Off

The preference record itself — the four-channel shape, the digest values, and the guarantee that a category missing from storage still comes back with its defaults — comes from the suite’s shared api-core notifications contract, which CPQ and Accounts serve too. The shape is common, but each product serves it at its own address, so a client still has to be pointed at the product it is reading. The ten categories and the defaults above are CRM’s own.

Every notification CRM raises is written to the notification centre and counted in the bell’s unread badge. That is the channel that delivers.

The email, push and SMS settings are stored but not acted on: no sender reads them, so ticking Email on a category sends no mail and there is no digest job. The API does accept push-device registration — a client can register a device token with its platform and app version, then list or remove its registrations — but nothing reads that registry to push anything.

Two things to plan around:

  • Submitting a record for approval raises no notification at all. The approver gets a high-priority task on their task list and nothing in the bell, so the task is the only signal that a request is waiting. The approval engine also attempts an email, which does not send in this release — see Email. Later stages do notify as usual: the deadline reminder, an escalation to a manager, and expiry all land in the centre.
  • Switching in-app off does not suppress anything. Notifications are always recorded and always listed, so clearing a category’s in-app box does not stop them appearing. Use the read/unread filter and mark all read to manage the noise instead.

Everything else — SLA breaches, escalations, assignments, mentions and case comments — stays inside CRM. Someone who is not in the app will not hear about it, so build escalation paths around the in-app centre and its unread badge.

CRM does send email elsewhere — quote delivery, password reset, and the Compose email screen, which sends through the server’s SMTP relay rather than through a mailbox anyone connected in the app. None of those consult the preferences above, and Email is where to check what does and does not send today. Posting a reply on a case is the one that looks like mail and is not: see Service & cases.

The API can also put a count next to a menu item. It computes badges for a fixed set of sources — unread notifications, open leads, my open cases, pending approvals, overdue activities and open deals — and serves them together in one call. Badges are opt-in per navigation item: the item has to carry a badge style (a count or a dot) and one of those six sources, and only non-zero counts come back. No shipped navigation item carries one, so the bell’s unread count is the badge users see in the app.

Notifications are raised by the rest of CRM — the workflow notify action, assignment, SLA and escalation events, approval requests, @-mentions and case comments. The preference categories above are named after those sources.

  • Automation — workflow rules and approvals emit notifications.
  • Service & cases — SLA, escalation and case-comment events notify the right people.