Notifications & preferences

Each product keeps a personal inbox: a bell in the app header with an unread badge, a full notification list behind it, and a per-user setting for which kinds of event you want to hear about. Two things are genuinely shared: the bell-and-list component, which all three take from the suite’s component library, and the shape of the preference record, which is the same five channels and the same digest values everywhere. That is why the three inboxes look alike and why a preference means the same thing wherever you meet it.

The plumbing behind them is each product’s own. CRM and CPQ drive their inboxes through the suite’s shared client; Accounts serves the same record from a client it wrote itself. That is invisible while you are using the apps, and it matters the moment you try to integrate — see The preference model.

What differs is how deeply each product has wired it up: which events actually raise a notification, whether switching a category off does anything, and which channels have something at the other end. This page is explicit about all three, because the preference screens are more generous than the delivery is.

Notifications are personal

Every read, mark-read, archive and preference change is scoped to the signed-in user. There is no role that grants sight of someone else’s inbox and none is needed — signing in to the workspace is what gets you your own, and nothing else. That is deliberate rather than a gap in the permission matrix described in Roles & permissions.

The one exception is raising a notification for somebody else. CPQ allows that, and unlike the rest of the inbox it is governed by the permission matrix like any other write. No screen offers it; it is there for integrations.

What raises a notification

Notifications come from the products themselves rather than from a rules screen you configure. The one place an administrator can raise one deliberately is the workflow notify action, and only in CRM and Accounts — CPQ’s equivalent action sends mail rather than writing to the centre.

Product	Events that land in the centre
CRM	Case assignment and queue routing, case comments and @-mentions on a case, SLA warnings and breaches, escalations, approval deadline reminders/escalations/expiry, and the workflow notify action.
CPQ	Customer engagement on a shared quote — the first time the customer opens it, and when they accept or decline it.
Accounts	Approval requests reaching you (including reassignment and escalation), the outcome of an approval you submitted, a dunning level increase on an invoice you raised, and the workflow send a notification action.

Three things follow from that table and are worth reading twice.

CPQ’s centre is narrow. Only quote-engagement events reach it. CPQ’s approval decisions and its workflow notification action go out as email instead, so the Approvals, Tasks and Workflow preference categories have nothing raising them in-app today. See Quote delivery for the engagement side and Quotes & approvals for the approval flow.

In CRM, submitting a record for approval raises nothing in the bell — the approver’s only signal is a high-priority task. Later approval stages do notify. Notifications in CRM has the detail, and Automation covers the approval run itself.

In Accounts, the Payments and System categories likewise have no producer yet: nothing currently writes an in-app notification under either, so leaving them on costs nothing and turning them off changes nothing. Approvals, Documents and General are the three that fill.

The notification centre

All three apps put the same bell in the header — unread badge, a dropdown or panel of the most recent items, mark-one-read and mark-all-read — and a fuller page behind it. The page is where they diverge.

	CRM	CPQ	Accounts
Full list page	Notifications	Notifications	Notifications
Refresh	Bell re-reads the count about once a minute	Every 30 seconds	Bell re-reads about once a minute
Read/unread filter	Yes	Yes (All / Unread / Read tabs)	Yes
Other filters	Type, priority and search are on screen but do not reach the list	Type, priority and related record — applied to the items already loaded	Category
Grouping	Newest first	Today / Yesterday / This week / Earlier	Inbox and Archived tabs
Paging	Yes	No — the page holds the most recent 20	Yes, with a page-size control
Removing an item	Delete, singly or in bulk — it is gone	Dismiss, which archives it	Archive, with an Archived tab to find it again
Click-through to the record	From the list page for cases, leads, deals and opportunities; an activity notification opens the Activities list rather than the activity; the bell dropdown jumps for cases only	When the notification carries a link	Yes, and the row also marks itself read

Because CPQ’s page has no paging and filters only what it has loaded, treat its type and priority filters as a way to scan the recent batch rather than to search history.

Accounts is the only one that lets you filter by category. CPQ records the category on each notification but its screen filters by type, priority and related record instead; CRM does not record it at all, so in CRM the categories exist for the preference screen alone and nothing in the centre can be grouped or narrowed by one.

The preference model

One preference record shape is shared by all three products. For each category you get:

In-app — whether the category belongs in your centre.
Email — whether the category should also be mailed to you.
Push and SMS — the mobile and text channels.
Email digest — how often the mailed ones should be batched: instant, hourly, daily, weekly, or off.

Two rules come with the shape and hold in all three products. Every category always comes back when you read your preferences, whether or not you have ever touched it — anything you have not saved is filled in from that product’s defaults. And resetting clears your stored overrides rather than writing the defaults down, so a later change to the defaults still reaches you.

What is not uniform is what happens to the cells you did not touch when you save. In CPQ and Accounts a save leaves them exactly as they were. In CRM it does not.

CRM’s preference grid saves each checkbox on its own, and each save writes all five channels of that category rather than the one you changed. The channels you did not touch are not preserved — they are rewritten to a generic baseline: in-app on, email off, push off, SMS off, digest Disabled.

Ticking Push on Assignments therefore also unticks that category’s Email box and drops its digest from Instant to Disabled. Changing the digest does the same in reverse: it unticks Email, which is what the digest control depends on, so the control greys out. In practice a CRM row cannot hold two departures from that baseline at once — the last box you touched is the one that sticks.

What it costs you today is an accurate record of intent, not a delivered message: in CRM none of email, push, SMS or the digest delivers anything (see Which channels actually deliver), and the in-app switch is not consulted either, so nothing arrives or fails to arrive because of this. Do not read the CRM grid as a statement of what a user asked for, and use Reset to defaults to put a mangled row back to a coherent state. CPQ and Accounts are unaffected.

The record shape, the digest values and the every-category-comes-back guarantee are the same in all three products. The endpoints are not. The three serve preferences at three different paths, and the bulk update is not even the same verb in each — so an integration written against one product’s preferences has to be re-pointed and re-fitted for the others rather than simply aimed at a new host. The category vocabulary is each product’s own too.

Product	Categories	Email on by default
CRM	Assignments, SLA alerts, Escalations, Activities, Approvals, Mentions, Comments, Status changes, Team updates, General — ten	Assignments, SLA alerts, Escalations, Approvals, Mentions
CPQ	Customer engagement, Approvals, Tasks, Workflow, System, General — six	Customer engagement, Approvals
Accounts	Approvals, Documents, Payments, System, General — five	Approvals

Defaults

The defaults follow one rule in all three products:

In-app starts on for every category, everywhere.
Push and SMS start off for every category, everywhere.
Email starts on only for the categories that need a person to act — the ones listed above.
The digest starts at Instant wherever email starts on; Daily for the routine categories (CRM activities and comments, CPQ tasks, Accounts documents and payments); and off for the rest.

Notifications in CRM sets out CRM’s ten categories row by row if you want to see the pattern written out.

Where the preferences screen lives

Product	Where	What the screen exposes	Saving
CRM	Notifications → Preferences, from a button in the notification list header	A grid with all four channel boxes — in-app, email, push, SMS — and the digest	Each change saves immediately and rewrites the rest of that row — see the caution above; Reset to defaults clears your overrides
CPQ	A Notification Preferences section at the foot of the Notifications page	In-app and Email switches only; the digest, push and SMS are not on the web screen	Each change saves immediately; Reset to Defaults clears your overrides
Accounts	Settings → Notifications, also reachable from your profile menu and from the bell	In-app switch, Email switch and the email-digest cadence; push and SMS are not offered	Edit freely, then Save changes; there is no reset control on the screen

Which channels actually deliver

This is the part to plan around. A channel with nothing at the other end is a stored setting, not a delivery route.

Channel	CRM	CPQ	Accounts
In-app	Delivers	Delivers	Delivers
Does switching In-app off suppress anything?	No — notifications are always recorded and always listed	Yes — a muted category is never recorded at all	No — notifications are always recorded and always listed
Email	Stored only	Stored only	Stored only
Email digest	Never runs	Never runs	Never runs
Push	Stored only; a device can be registered but nothing is pushed	The switch is honoured, but no push provider is connected, so nothing arrives	Not offered — no push at all
SMS	Stored only	Stored only, and not on the web screen	Not offered

Three consequences:

Turning a category off only does something in CPQ, and there it does rather a lot: the notification is never written, so it is not hidden — it does not exist, and you cannot go back for it later. In CRM and Accounts the switch is a statement of intent; use the read/unread filter and mark all read to manage noise instead.

Ticking Email sends no mail in any of the three. All three products do send mail elsewhere — CPQ for quote delivery and approval decisions, Accounts for dunning reminders and emailed documents, CRM for quote delivery, password reset and the Compose screen — but none of those sends consults these switches, and none of them can be turned on or off from here. See Email in CRM, Quote delivery and Dunning and collections.

Nobody is reachable off-app. Someone who is not signed in will not hear about an SLA breach, an approval waiting or an overdue invoice until they open the product. Build escalation paths around the in-app centre and its unread badge, and pair anything genuinely urgent with a channel outside the suite.

On the phone

The mobile apps read the same inbox but do not close the gap.

CPQ’s sales, Partner Hub and Field Service apps carry the in-app centre with its unread badge, and the sales app’s settings carry the same preferences plus a push switch — but push is not delivered. See CPQ mobile.
Accounts’ app has Notifications and Approvals in its drawer with live counts, fed by a single badge call. See Accounts mobile.
CRM’s app has no notification centre and never registers for push. See CRM mobile.

Good practice

Set expectations with your team: the bell is the notification system. Anyone who needs to act on an approval or an SLA has to be in the app.
Leave in-app on everywhere. In CRM and Accounts turning it off achieves nothing; in CPQ it destroys the record rather than filing it away.
Use the categories to plan, not to filter. Only Accounts lets you narrow the centre by category; in CRM the category is not even recorded on the notification.
Ask your administrator to configure the workflow notify action where a business event ought to reach someone and does not already — CRM automation and Accounts workflows both have one, and it writes into the same centre.

Where the detail lives

Notifications in CRM — the fullest per-product account: the centre, the ten categories, the defaults row by row, and the navigation badge counts.
Platform & settings in Accounts — where the notification screen sits among Accounts’ admin surfaces.
Quote delivery in CPQ — the engagement events behind CPQ’s notifications.

Connects to

Roles & permissions — why your inbox needs no grant.
Customization — the workflow engines that can raise a notification.