Push Notifications, Mobile
A mobile push notification is an alert that the Salesforce mobile app delivers to a user's phone or tablet about an event in Salesforce, even when the app is closed.
Definition
A mobile push notification is an alert that the Salesforce mobile app delivers to a user's phone or tablet about an event in Salesforce, even when the app is closed. The message can appear on the device lock screen or in the notification center, so the user learns about an approval request, a Chatter mention, a task assignment, or a custom event without opening the app first.
Push notifications come in two flavors. Standard notifications cover use cases that Salesforce predefines, such as approval requests and @mentions. Custom notifications are ones an admin or developer defines for business events that matter to a specific org. Both flow through the same plumbing and reach the device through Apple and Google notification services.
How mobile push reaches the device
In-app notifications versus push notifications
Salesforce treats in-app and push as two related but separate channels, and the distinction trips up a lot of admins. An in-app notification is the bell icon inside the Salesforce mobile app, the list a user sees after they open the app and tap the bell. A push notification is the alert that the operating system shows on the lock screen or banner while the app sits in the background or fully closed. The two are linked by a rule worth memorizing. To turn on push notifications for the org, you must also have in-app notifications enabled. In-app is the prerequisite, push is the layer on top. You enable both from the same Notification Settings page in Setup. Once push is on at the org level, each user still controls whether their own device receives push, through their mobile app settings and their device's OS settings. So an admin can enable the capability, but a user who declined the OS permission prompt will not see anything on their lock screen. When you debug a missing notification, check both the org switch and the individual device permission.
The delivery path through Apple and Google
A Salesforce push notification does not travel straight from your org to the phone. It hops through the platform that the device vendor operates. For iPhones and iPads that is the Apple Push Notification service. For Android devices it is Firebase Cloud Messaging, the Google service that replaced the older Google Cloud Messaging. When an event fires, Salesforce hands the message to the right provider, and the provider pushes it down to the registered device. This matters for two reasons. First, the device vendors enforce their own throughput limits, so very high notification volume can be throttled outside Salesforce's control. Second, delivery is best effort, not guaranteed. If a device is offline, powered down, or the OS has cleared the app from memory in an aggressive way, a push can be delayed or dropped. Treat push as a prompt to look at Salesforce, not as the system of record. Anything that truly must be acted on should also live in a report, a list view, or an approval queue that the user can reach on their own.
Standard notifications you get for free
A fresh org already has a set of standard notification types that Salesforce ships and maintains. These cover the common moments where a user needs a nudge. Approval requests arrive when a record enters an approval process and the user is an assigned approver. Chatter activity, such as an @mention, a comment on a post the user follows, or a new follower, can generate a notification. Task and event reminders, case-related alerts, and announcements round out the list. You do not build any of these. You enable the channel, and the predefined types start flowing based on what each user is involved in. Admins can influence the volume through related features, for example by tuning which Chatter emails and feeds a user receives, but the notification types themselves are fixed. Standard notifications are the fastest way to get value from mobile push, because the only configuration is the org-level switch plus each user opting in on their device. For many orgs the standard set covers eighty percent of what people actually want to be alerted about.
Custom notifications for your own events
When the standard list does not cover a business event, you reach for a custom notification. The building block is a Custom Notification Type, a metadata record you create in Setup that names the notification and picks its channels, desktop, mobile, or both. After the type exists, you send notifications of that type from automation or code. The common senders are Flow, Apex, and the Connect REST API. A record-triggered flow can fire a custom notification when a high-value opportunity closes or a priority case is reopened. Apex uses the Messaging.CustomNotification class to set a title, a body, a target record, and a recipient list, then call send. The Connect REST API lets an external system trigger the same notification. Whatever the sender, you specify recipients (users, groups, queues, or a record owner) and a target record that the notification deep-links to. Tapping the alert opens that record inside the Salesforce mobile app, which turns a passive ping into a one-tap path to the work.
Full content versus minimal content
Push notifications can reveal the actual message text on the lock screen, or they can hide it. Salesforce calls this full content versus minimal content, and it is an org-level choice on the same settings page. Full content is the default for the Salesforce mobile app. With it on, the body of the notification, such as the record name or the approval subject, shows on the lock screen before the user authenticates. Minimal content strips the detail down to a generic prompt that tells the user to open Salesforce, without exposing the underlying data. Regulated industries often switch to minimal content so that sensitive record names or customer details never appear on an unlocked-glance screen. The trade-off is convenience. Full content lets a user triage at a glance, while minimal content forces them into the app to see what happened. Pick based on your data sensitivity, not on habit. If you handle health, financial, or other regulated records, minimal content is usually the safer default even though it adds a step.
Designing for signal, not noise
The biggest risk with mobile push is not technical, it is behavioral. People silence apps that cry wolf. If every record edit triggers an alert, users mute Salesforce in their OS settings within a week, and then even the genuinely urgent approval goes unseen. Mature deployments are deliberate about which events deserve a push. A useful test is whether the event needs action within hours, not days. Approval requests, escalated cases, and at-risk deals pass that test. A routine field change usually does not. Lean on entry criteria in your flows so a custom notification fires only when the record truly qualifies, for example only when an opportunity above a revenue threshold reaches a late stage. Give users a way to manage their own preferences too, so power users and occasional users can each find a comfortable volume. The goal is a channel people trust, where a buzz from Salesforce reliably means something worth their attention.
Enable Salesforce mobile push notifications
Push notifications are off until an admin enables the channel at the org level. The steps below turn on both in-app and push for the Salesforce mobile app, then point you at custom notifications for org-specific events.
- Open Notification Settings
In Setup, use the Quick Find box to search for Notification Settings (under the Salesforce mobile app section) and open the page.
- Enable in-app, then push
Turn on in-app notifications first, since push depends on it, then enable push notifications for the org. Save your changes.
- Choose a content level
Decide between full content and minimal content for lock-screen display. Keep full content for convenience, or switch to minimal content if you handle sensitive data.
- Add custom notifications if needed
For business-specific events, create a Custom Notification Type, pick the mobile channel, then send it from a record-triggered flow, Apex, or the Connect REST API.
- Confirm on a device
Have a test user accept the OS permission prompt in the Salesforce mobile app, then trigger an event and verify the alert appears on their lock screen.
The bell-icon list inside the app. Must be enabled before push works.
Lock-screen and banner alerts delivered while the app is backgrounded or closed.
Whether the notification body shows on the lock screen or is hidden behind a generic prompt.
A metadata record that defines a custom notification and its desktop or mobile channels.
- Push will not work unless in-app notifications are also enabled in the same org settings.
- Each user must accept the operating system permission prompt on their device, or no push appears regardless of org settings.
- Delivery runs through Apple APNs and Google FCM and is best effort, so do not rely on push as the only signal for critical work.
- Over-notifying trains users to mute the app, so gate custom notifications behind tight entry criteria.
Prefer this walkthrough as its own page? How to Push Notifications, Mobile in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Push Notifications, Mobile.
Hands-on resources to go deeper on Push Notifications, Mobile.
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.
Test your knowledge
Q1. What are Push Notifications in the Salesforce Mobile App?
Q2. When a regional VP taps an approval Push Notification on her phone, what does it do?
Q3. What is the risk of configuring mobile Push Notifications too broadly?
Discussion
Loading discussion…