Real-Time Communication in Salesforce
Introduction
Modern Salesforce applications are more dynamic and connected than ever. Users expect instant feedback, real-time synchronization, and a seamless experience across devices and teams. Whether it’s notifying users about updates, syncing data between interface components, or reflecting changes triggered by background processes, real-time communication has become a key capability in the Salesforce platform.
Salesforce provides several built-in mechanisms to handle these scenarios – Platform Events, the Streaming API, and the pub/sub model within Lightning Web Components (LWC). Each of these serves a different purpose, enabling developers to design reactive, event-driven architectures that are efficient and maintainable.
In this article, we’ll explore these mechanisms in depth, understand their differences, and see how they can be combined to create scalable, responsive Salesforce applications.
Why Real-Time Communication Matters
Traditional request-response interactions – such as Apex calls or wired data queries – are useful for direct operations but often insufficient in large-scale, asynchronous systems. Many modern business processes require non-blocking, event-driven updates that reflect changes as they happen.
Typical Real-Time Scenarios
- A sales representative views an Opportunity, and the related Quote is approved by another user – the Opportunity view should update automatically;
- A background integration updates order statuses based on ERP data – the user dashboard must reflect new statuses immediately;
- A Flow completes document generation – users should be notified instantly without manual page refresh.
Without real-time communication, users experience stale data, delayed insights, and inconsistent interfaces. Event-driven communication solves this by enabling systems and components to react to changes as they occur, rather than waiting for polling or refresh cycles.
Key Principle: Real-time communication turns Salesforce from a passive data viewer into an active, event-aware platform that responds instantly to change.
Platform Events
Platform Events are Salesforce’s implementation of event-driven architecture inside the platform. They enable decoupled, asynchronous communication between different parts of Salesforce and external systems.
You can think of them as custom event definitions, similar to objects, but optimized for message passing rather than data storage. Publishers send messages to the Salesforce event bus, and subscribers react to those messages independently.
Use Cases:
- Backend processing: Trigger asynchronous Apex logic or Flow automation;
- System integration: Connect Salesforce with external apps (ERP, middleware, IoT);
- Data synchronization: Notify other processes when important state changes occur.
Example: Publishing from Apex
Order_Update__e event = new Order_Update__e(
OrderId__c = 'O-10001',
Status__c = 'Shipped'
);
Database.SaveResult sr = EventBus.publish(event);
Example: Consume it in a Lightning Web Component using the empApi module
import { LightningElement, track } from 'lwc';
import { subscribe, onError } from 'lightning/empApi';
export default class OrderListener extends LightningElement {
channelName = '/event/Order_Update__e';
connectedCallback() {
subscribe(this.channelName, -1, (event) => {
console.log('Received event:', event.data.payload);
});
onError(error => console.error('Error:', error));
}
}
Advantages:
- Decoupled communication between producers and consumers;
- Supports replay of past events (within 24 hours);
- Ideal for asynchronous system-level notifications.
Limitations:
- Short delivery delay (not true instant streaming);
- Event retention limited to 24 hours;
- Consumption limits per 24-hour period.
Streaming API
The Streaming API is Salesforce’s mechanism for near-real-time data delivery to clients, especially user interfaces. It uses the CometD protocol (a form of long polling) to push data from Salesforce to subscribed clients the moment changes occur.
This makes it ideal for live dashboards, monitoring consoles, and data views that need to update instantly when records are modified.
Example: Subscribing to CDC Events
import { LightningElement } from 'lwc';
import { subscribe, onError } from 'lightning/empApi';
export default class AccountListener_CDC extends LightningElement {
channelName = '/data/AccountChangeEvent';
subscription;
connectedCallback() {
subscribe(this.channelName, -1, (message) => {
const payload = message.data.payload;
const header = payload.ChangeEventHeader;
console.log('CDC received:', header.changeType, header.recordIds);
}).then((res) => (this.subscription = res));
onError((err) => console.error('CDC stream error:', err));
}
}
Use Cases:
- Live data views and dashboards;
- Monitoring record changes across users;
- Building collaborative, real-time interfaces.
Advantages:
- Low latency – near-instant delivery;
- Integrated with empApi for simple use in LWCs;
- Supports multiple event types (CDC, PushTopic, etc.).
Limitations:
- Long-polling protocol (not true WebSockets);
- No guaranteed delivery for offline clients;
- Event replay is limited to recent messages.
Pub/Sub in Lightning Web Components
When multiple Lightning Web Components live on the same page, they often need to share state or communicate actions without involving Apex or the Salesforce server. For these cases, Salesforce provides a local pub/sub pattern – a simple, event-based communication mechanism for LWC-to-LWC messaging.
This model lets one component publish a message, and any other component on the same page can subscribe to it. It’s lightweight, fast, and keeps communication client-side.
Why Use Local Pub/Sub:
- No server round-trips – everything happens in the browser;
- Keeps components loosely coupled – no direct parent-child dependencies;
- Ideal for modular applications where multiple components need to react to the same event (e.g., filters, tabs, charts).
Example: Implementation
const events = {};
const subscribe = (eventName, callback) => {
if (!events[eventName]) events[eventName] = [];
events[eventName].push(callback);
};
const publish = (eventName, payload) => {
if (events[eventName]) {
events[eventName].forEach(callback => callback(payload));
}
};
export { subscribe, publish };
Publisher Component:
import { LightningElement } from 'lwc';
import { publish } from 'c/pubsub';
export default class FilterPublisher extends LightningElement {
handleFilterChange(event) {
publish('filterChanged', { value: event.target.value });
}
}
Subscriber Component:
import { LightningElement } from 'lwc';
import { subscribe } from 'c/pubsub';
export default class FilterListener extends LightningElement {
connectedCallback() {
subscribe('filterChanged', (data) => {
console.log('Filter updated:', data.value);
});
}
}
Benefits:
- Extremely low latency – instant UI updates;
- No dependency on Apex or backend services;
- Ideal for dynamic dashboards or multi-widget pages.
Limitations:
- Works only within a single Lightning page context;
- Does not persist across page navigation;
- Not suitable for cross-user or cross-session communication.
When to Use Each Approach
Choosing the right mechanism depends on what you’re trying to achieve – whether it’s system-wide integration, user interface updates, or component-level coordination. Each option has its own strengths and ideal use cases.
Platform Events
Use Platform Events when you need to enable asynchronous communication between different parts of Salesforce or between Salesforce and external systems.
They shine in situations where processes should happen independently – one process publishes an event, and multiple consumers can react to it without tight coupling.
Typical scenarios include:
- Backend automation that runs in response to business triggers (e.g., “Order Shipped”, “Payment Processed”);
- Integrations between Salesforce and middleware such as MuleSoft, AWS, or external APIs;
- Decoupling long-running or complex operations from user actions.
Because Platform Events are reliable, replayable, and persistent for 24 hours, they’re excellent for backend workflows, but they’re not truly instantaneous.
If your use case involves real-time updates on a user interface, they should usually be combined with other tools – for example, using a Platform Event to start a background job, and a Streaming API channel to notify the user interface once data has changed.
Streaming API
The Streaming API is the right choice when you need immediate, user-facing updates without refreshing the page. It’s particularly effective for:
- Dashboards that need to reflect live record changes;
- Monitoring systems showing real-time KPIs or operational data;
- Collaborative apps where multiple users work with the same records simultaneously.
Because the Streaming API uses long polling (CometD), it delivers messages to the browser in near real time — often within milliseconds after a change is committed to the database.
This makes it ideal for reactive interfaces, where users should see updates as soon as they occur elsewhere in the system.
When using the Streaming API:
- Keep your channel subscriptions focused — subscribe only to the objects or fields you need;
- Be mindful of platform limits and network resources; too many active subscriptions can impact performance;
- Always unsubscribe in disconnectedCallback() to avoid resource leaks in Lightning Web Components.
If your app needs record-level change tracking and real-time UI refreshes, Change Data Capture (CDC) – which runs on top of the Streaming API – is often the best fit.
Pub/Sub in Lightning Web Components
Finally, when the communication is purely client-side, within a single Lightning page, the lightweight pub/sub pattern in Lightning Web Components is the most efficient option.
This pattern is ideal when:
- Two or more LWCs need to react to shared user actions (for example, changing a filter or selecting a record);
- Multiple components display different aspects of the same data set and should stay in sync;
- You want to avoid unnecessary Apex calls just to pass small messages between components.
Since this mechanism operates entirely in the browser, it’s instantaneous and requires no server interaction. However, it’s limited to the current page context – navigating away or reloading the page resets the event bus.
It also doesn’t support cross-user or cross-session communication, so it’s strictly for coordinating components within a single Lightning view.
Combining multiple mechanisms
In complex applications, these approaches are often combined to build layered, event-driven systems that balance speed, reliability, and scalability.
Here’s a common example:
- A backend process publishes a Platform Event when an order’s shipping status changes;
- Salesforce processes that event and updates the relevant records, which in turn trigger Change Data Capture (CDC) events;
- The Streaming API delivers those CDC events to LWCs subscribed to the order management page;
- Within that page, several components use local pub/sub to share the update and refresh different UI sections simultaneously.
This pattern creates a complete, end-to-end event flow:
- Platform Events handle backend logic and integration;
- Streaming API delivers real-time updates to the interface;
- LWC pub/sub ensures instant synchronization between individual UI elements.
By layering these mechanisms together, you can create Salesforce applications that are scalable, resilient, and highly responsive – capable of reflecting business changes the moment they happen.
Conclusion
Salesforce provides multiple mechanisms for real-time, event-driven communication, each tailored for specific use cases:
- Platform Events handle asynchronous system-to-system and backend processes;
- Streaming API delivers near-instant data changes directly to the user interface;
- Pub/Sub in LWC supports local, lightweight communication between components on the same page.
Understanding these tools and their differences is critical for building modern, interactive Salesforce applications that scale efficiently while providing users with up-to-date information at all times.
As Salesforce continues to evolve its event-driven capabilities – particularly through enhancements to Change Data Capture and real-time UI frameworks – developers who master these communication models will be well-positioned to build the next generation of connected Salesforce experiences.
