Custom Notification
A Custom Notification in Salesforce is an admin-defined, in-app alert that gets pushed to specific users through the desktop bell icon in Lightning Experience, the Salesforce mobile app, or both.
Definition
A Custom Notification in Salesforce is an admin-defined, in-app alert that gets pushed to specific users through the desktop bell icon in Lightning Experience, the Salesforce mobile app, or both. It is fired from automation (Flow, Process Builder, Apex, or the REST API), so teams can raise targeted alerts like "high-value Opportunity went quiet" or "VIP customer just logged a Case" without building any mobile push plumbing.
Every Custom Notification points back to a Custom Notification Type, a reusable record that names the alert and turns the Desktop and Mobile channels on or off. Once the type exists, automation references it and supplies a title, a body, the recipient IDs, an optional sender, and an optional target record. Salesforce then delivers the message across the channels that the type has enabled.
How Custom Notifications are built and delivered
The Custom Notification Type record
Before anything can fire, an admin creates a Custom Notification Type under Setup, Notification Builder, Custom Notifications. The type is stored in the CustomNotificationType object, available in API version 47.0 and later. It carries a Custom Notification Name (the API name), a label that users see, an optional description, and two channel checkboxes: Desktop and Mobile. Desktop sends to the bell icon in Lightning Experience. Mobile sends a push to the Salesforce mobile app on iOS and Android. A type can enable one channel or both. Think of the type as a reusable category, not a single message. You might define one type called "Sales Risk Alerts" and reuse it across many automations, each supplying its own title and body at send time. Because the type controls the channels, switching a notification from desktop-only to mobile-and-desktop is a checkbox change on the type, not an edit to every automation. Types are also deployable through Metadata API and queryable through Tooling API, so they move cleanly between sandboxes and production with the rest of your config.
Sending from Flow and Process Builder
The most common way to fire a Custom Notification is the Send Custom Notification action in Flow Builder. You add an Action element, search for Notifications, and pick Send Custom Notification. The action asks for the Custom Notification Type ID, a Notification Title, a Notification Body, and a Recipient IDs collection. You usually fetch the type ID first with a Get Records element on CustomNotificationType, then pass that ID into the action. Title and body accept plain text or merge fields, so you can fold record data straight into the message. The Recipient IDs collection holds the IDs of who should receive the alert. Process Builder exposes the same capability through its own Send a Custom Notification action, which is handy on older orgs still running processes. Both routes are declarative, so an admin can stand up a working alert without code. A record-triggered flow on Case, for example, can fire the notification the moment an SLA field flips, with no Apex anywhere in the path.
Who can receive a notification
Custom Notifications are not limited to individual users. The Recipient IDs collection can contain user IDs, but it also accepts group IDs, queue IDs, and role IDs. When you pass a public group, every member of that group receives the alert. When you pass a queue, the queue members receive it. This matters for maintainability. Hard-coding a list of user IDs into a flow means editing the flow every time the team changes. Pointing the notification at a public group means you update the group membership in Setup and the automation keeps working untouched. The same logic applies to roles and queues. For a support desk that rotates staff often, sending to a "Tier 2 Support" queue is far more durable than naming people. One caveat on mobile: a recipient only gets the push if they have the Salesforce mobile app installed and notifications enabled on their device. The desktop bell still lights up for them either way, so the alert is not lost.
Sending from Apex with Messaging.CustomNotification
When the logic outgrows Flow, developers reach for the Messaging.CustomNotification class in Apex. You create an instance, then set its parts with setNotificationTypeId, setTitle, setBody, and optionally setSenderId. To make the notification clickable, you target a record with setTargetId, or target a specific page with setTargetPageRef. Finally you call send with a Set of recipient IDs. The Apex path shines when recipients come from a SOQL query, when the message depends on multi-object logic, or when notifications need to batch across large populations. A worked pattern: a nightly batch job queries Opportunities above a probability threshold with no recent activity, builds a Set of owner IDs, and calls send once per chunk. Because send accepts a Set, you deduplicate recipients for free. Wrap the send in try-catch, since a bad type ID or an empty recipient set throws, and you want the batch to log and continue rather than fail the whole run.
Target records and the tap-to-open experience
A notification without a destination is a dead end. The recipient reads "Opportunity at risk" and then has to go find the record themselves. Setting a target fixes this. In Flow the action does not expose a target field directly the way Apex does, so deep-linking behavior depends on how the notification is constructed and the platform version, while in Apex setTargetId(recordId) makes the whole notification clickable straight to that record. On the desktop bell, clicking opens the record in the same tab. On mobile, tapping the push opens the record inside the Salesforce app. For notifications that should land somewhere other than a record detail page, setTargetPageRef accepts a serialized PageReference, which can point at a list view, a custom tab, or a component. Getting the target right is the single biggest lift to how useful the notification feels. The body tells the recipient what happened; the target gets them to the thing they need to act on in one click.
Limits, channels, and content rules
Custom Notifications carry platform limits you should design around. A single notification can target up to 10,000 recipients, and an org can send up to 10,000 notification actions per hour. If you need to alert a population larger than 10,000, you split the send into multiple actions, which is straightforward in Apex by chunking the recipient set. The notification body is plain text, not HTML, so formatting tricks do not survive; keep the message short and lead with the part that matters. Mobile delivery is best-effort. A device that is offline receives the push when it reconnects, and a user without the app installed simply relies on the desktop bell. There is no built-in archive of what was sent, so the platform does not keep a readable history of past notifications for you. If your governance needs an audit trail of who was alerted and when, you build that logging yourself, typically by writing a record to a custom object in the same automation that fires the notification.
Custom Notifications versus email and standard notifications
It helps to place Custom Notifications next to the alternatives. Email Alerts, fired from Flow or Process Builder, deliver an email that lands in an inbox, persists, and can reach people outside Salesforce. They suit messages that need a paper trail or external delivery, but they compete with every other email and are easy to miss. Custom Notifications interrupt the user inside Salesforce, which is exactly what you want for time-sensitive work and exactly what you do not want for routine FYI traffic. Standard notifications, the ones Salesforce generates for approvals, @mentions, and assigned tasks, also use the bell, but you do not author those; Custom Notifications are the path when you need your own domain-specific alert. The practical rule: reach for a Custom Notification when a human needs to act soon and the action lives in Salesforce. Reach for email when the message needs to persist or travel outside the platform. Mixing the two thoughtfully keeps the bell meaningful and the inbox uncluttered.
How to create a Custom Notification Type
A Custom Notification Type is the reusable record that names your alert and decides which channels carry it. You create it once in Setup, then automations reference it by ID. Here is the path to stand one up.
- Open Notification Builder
In Setup, use the Quick Find box to search for Custom Notifications, then open it under Notification Builder. This is where every notification type for the org lives.
- Create a new type
Click New, then give the type a Custom Notification Name (the API name automation will reference) and a label that recipients will see on the alert.
- Choose the channels
Check Desktop to light up the Lightning bell icon, Mobile to push to the Salesforce mobile app, or both. The type controls delivery, so changing channels later is a checkbox edit here.
- Save and grab the ID
Save the type. In your Flow, add a Get Records element on CustomNotificationType filtered by the name so you can pass its record ID into the Send Custom Notification action at runtime.
The API name of the type. Automation references this name (via a Get Records lookup) to resolve the type ID at send time.
At least one of Desktop or Mobile must be enabled, or the notification has nowhere to deliver. Both can be on at once.
- The type only defines channels and a label. The title and body are supplied per send by the automation, not stored on the type.
- Mobile push only reaches users who have the Salesforce mobile app installed with notifications allowed; the desktop bell still fires for everyone.
- Deploy types through Metadata API or a change set so the IDs and names stay consistent between sandbox and production.
Prefer this walkthrough as its own page? How to Custom Notification in Salesforce, step by step
Trust & references
Cross-checked against the following references.
- Send Custom Notification ActionSalesforce
- CustomNotification Class (Apex Reference Guide)Salesforce
Straight from the source - Salesforce's reference material on Custom Notification.
Hands-on resources to go deeper on Custom Notification.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Discussion
Loading discussion…