Push Notifications, Salesforce Console
Push Notifications in the Salesforce Console are visual indicators that appear in the Salesforce Classic console when a record or field an agent is viewing gets changed by another user or a system process.
Definition
Push Notifications in the Salesforce Console are visual indicators that appear in the Salesforce Classic console when a record or field an agent is viewing gets changed by another user or a system process. They keep a support agent's screen current so two people working the same case or account do not step on stale data. The feature is built on the Streaming API and is configured per console app in Setup.
This is a Salesforce Classic console feature. It is considered legacy because Lightning console apps, the Service Console and Sales Console, do not carry the same push notification configuration forward. If you are building new, you reach for Lightning list view auto-refresh, Change Data Capture, or Platform Events instead of Classic console push notifications.
How Classic console push notifications actually behaved
Two notification styles: list updates and detail updates
Console push notifications came in two flavors, and an admin chose them separately per console app. List updates governed what happened inside a list view in the navigation tab or a pinned list. You could set the list to do nothing, refresh the whole list, or refresh only the affected rows when a watched field changed. Refreshing just the rows kept the agent's scroll position steady instead of jumping the whole grid. Detail updates governed what happened on an open record. The two options were Automatically Refresh, where the detail page quietly reloaded to show the new values, and Flag, where a small message appeared on the page telling the agent the record had changed so they could refresh on their own terms. Flag was gentler for agents in the middle of typing, since an automatic refresh could wipe unsaved edits. Most service teams picked row refresh for lists and Flag for details, so agents stayed informed without losing their place or their work in a busy queue.
Which objects and fields you could watch
An admin did not flood agents with every change. You picked specific objects, then specific fields on those objects, and only changes to those chosen fields fired a notification. Eight object types were supported: Accounts, Contacts, Cases, Leads, Opportunities, Campaigns, Tasks, and custom objects. For a service team, Cases was the obvious target. You might watch Status, Priority, and Owner, so an agent saw the moment a case was escalated or reassigned out from under them. Choosing fields carefully mattered for two reasons. Too many watched fields generated noise and made the console feel jumpy, since every minor edit triggered a refresh or a flag. Too few meant agents missed the changes that actually mattered to their work. The field picker sat right inside the console app definition in Setup, so the configuration lived with the app rather than in a separate global setting. This per-app scoping let a support console and a sales console watch entirely different objects and fields.
What the agent saw on screen
The visual language was simple and lived mostly in list views. A row highlighted in yellow meant that record had been modified by someone else. A row highlighted in blue marked the last item the agent had opened, so they could find their place again after a list refreshed. Fields the admin had configured for notifications showed in bold and italic, drawing the eye to exactly what changed rather than the whole row. On an open detail page the behavior depended on the admin's choice. With Automatically Refresh, the page reloaded and the new values simply appeared. With Flag, a short message surfaced on the page announcing the change, and the agent decided when to reload. These cues were designed for the high-volume reality of a contact center, where one agent might have a dozen cases open across console tabs and needed a fast, glanceable signal that something behind one of those tabs had moved.
The Streaming API engine underneath
Console push notifications were not magic. They rode on the Streaming API, the same publish-and-subscribe pipe that powered PushTopic events. When you configured notifications, the platform managed the underlying subscription so the console listened for changes to the records and fields you selected, then pushed those changes to the agent's browser in near real time. This is why the feature granted users Read access on the PushTopic standard object as part of setup. It is also why the feature was tied to the limits and behavior of the Streaming API rather than to a simple page poll. Understanding this lineage helps when you read older console implementations. The push notification config in the app, the PushTopic permission, and the Streaming API all worked together. If notifications stopped firing, the cause was usually one of those three layers: the field was not selected, the user lacked PushTopic read, or a Streaming API constraint had been hit.
Edition, permission, and security gotchas
A few hard requirements decided whether the feature even worked. The console itself was unavailable in Professional Edition, so push notifications were too. Configuring them required the Customize Application permission, the standard admin-level right for editing app and metadata setup. Agents needed Read on the PushTopic object for the subscription to deliver to them. The sharpest gotcha was a security setting. Console push notifications were incompatible with the Require HttpOnly attribute session setting. If your org enabled HttpOnly to harden session cookies, push notifications quietly failed, which made for a confusing support ticket because nothing in the console config looked wrong. Streaming API also had to be enabled for the org. None of these were obvious from the console app editor alone, so a working setup meant checking the edition, the admin permission, the agent permission, the HttpOnly session setting, and the Streaming API status together rather than one at a time.
Why it is legacy and what replaced it
Salesforce has steadily moved customers from the Salesforce Classic console to Lightning console apps, the prebuilt Service Console and Sales Console. The Lightning console does not carry forward the Classic push notification configuration. Salesforce documentation for Lightning console apps explicitly lists push notifications among the Classic features without full parity in Lightning. That does not leave you without options. Lightning list views can refresh on a set interval, so a queue updates without manual reloads. For record-level change detection in custom components, Change Data Capture and Platform Events give you a modern event stream that Apex, flows, and Lightning Web Components can subscribe to. Lightning Message Service and the lightning/refresh module let components react to data changes in the same app. The practical takeaway: keep Classic console push notifications running if you still live in Classic, but do not build new dependencies on them. Plan the move to a Lightning console and rebuild the real-time behavior with list auto-refresh and event-driven patterns.
Configuring push notifications on a Classic console app
These steps reflect configuring push notifications on a Salesforce Classic console app. They are here for maintaining existing Classic implementations. For new builds, use a Lightning console with list auto-refresh and event-driven updates instead.
- Open the console app
In Setup, use Quick Find to open Apps, then edit the Salesforce Classic console app you want to configure. Push notification settings live inside the app definition, not in a separate global page.
- Set list update behavior
Under the push notifications section, choose how lists react: do nothing, refresh the whole list, or refresh only the affected rows. Row refresh keeps the agent's scroll position steady in a busy queue.
- Set detail update behavior
Choose how an open record reacts: Automatically Refresh to reload the page with new values, or Flag to show a message so the agent refreshes on their own terms. Flag avoids wiping unsaved edits.
- Pick objects and fields to watch
Select the objects (Cases, Accounts, custom objects, and so on), then the specific fields whose changes should fire a notification. Watch only the fields that matter, such as Case Status, Priority, and Owner, to avoid noise.
- Grant agents PushTopic read access
Give the agent profiles or permission sets Read access on the PushTopic standard object so the Streaming API subscription can deliver notifications to their console.
Whether a list does nothing, refreshes fully, or refreshes only the changed rows when a watched field changes.
Automatically Refresh reloads the open record; Flag posts a change message and leaves the refresh to the agent.
The chosen objects and the specific fields on them that trigger notifications when they change.
- Push notifications are unavailable in Professional Edition because the console itself is not available there.
- They are incompatible with the Require HttpOnly attribute session setting; enabling HttpOnly silently breaks notifications.
- Streaming API must be enabled, configuring requires Customize Application, and agents need Read on the PushTopic object.
- Lightning console apps do not carry this configuration forward, so plan list auto-refresh and event-driven patterns for any migration.
Prefer this walkthrough as its own page? How to Push Notifications, Salesforce Console in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Push Notifications, Salesforce Console.
Hands-on resources to go deeper on Push Notifications, Salesforce Console.
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 do Push Notifications do in the Salesforce Classic console?
Q2. Why are Salesforce Console Push Notifications described as a Classic-era concept?
Q3. What problem did Classic console Push Notifications solve for agents working the same records?
Discussion
Loading discussion…