Platform Events enable real‑time, event‑driven integrations both within and beyond Salesforce. They provide a powerful, scalable way to publish and subscribe to custom event messages. In this blog, we will cover key terminology, core concepts, implementation steps, best-practice scenarios, and discuss how to publish from Apex, from an Autolaunched Flow, and from an external application using the Salesforce API.
Key Terms and Overview
A Platform Event is a custom event message defined under Setup → Platform Events, with an API name ending in __e. Publishers are processes that create (publish) these messages, whether Apex code, Flow, or external systems, while subscribers listen and react via Apex triggers, Lightning components (EmpAPI), or CometD clients.
We can choose “Publish Immediately” to trigger an event as soon as Apex calls EventBus.publish, or “Publish After Commit” to ensure it only goes out once the transaction is successful. Durable subscriptions allow external clients to replay missed events, while non‑durable ones deliver only in real time.
Below are the screenshots of how we can find platform events in the setup:
Click on New Platform Event:
Fill all the details properly as per the business requirements, and then we are good to move forward.
Understanding Platform Events
Platform Events treat each message like a lightweight record on an internal event bus. Publishers write the event, Salesforce holds it temporarily, and then pushes it to every active subscriber. After delivery or once the retention window passes, the message is purged. This decoupling means publishers don’t need to know who listens, and subscribers can rebalance or replay events independently.
How are Platform Events different from Change Data Capture?
Platform Events give you complete control over our message schema, making them perfect for scenarios that require custom metadata or signals beyond simple record changes. By contrast, Change Data Capture (CDC) automatically streams create, update, delete, and undelete events for Salesforce records, but only for objects we choose to track. CDC is ideal when we simply need to broadcast data changes without crafting a custom payload.
Outbound Messages, part of the legacy workflow engine, push SOAP‑based notifications to a single external endpoint whenever a rule fires. They operate synchronously and point‑to‑point, meaning the workflow waits for the external service to acknowledge the message.
Platform Events use a publish/subscribe architecture, allowing a single event to reach multiple consumers. Even if one subscriber is offline, other subscribers will still receive the message. Durable subscribers can even replay missed events after downtime, which Outbound Messages cannot.
Meanwhile, Apex callouts represent a synchronous, request‑response model where our code pauses execution until an external service returns data. Platform Events invert this by letting the code publish an event asynchronously, fire‑and‑forget, so we can avoid transaction delays and the risk of timeouts. Subscribers then pick up and process the event on their schedule, enabling higher throughput and looser coupling.
Platform Events vs. Other Salesforce Messaging
Feature | Platform Events | Change Data Capture | Outbound Messages | Apex Callouts |
Primary Use | Custom, event‑driven integrations | Record‑change notifications | SOAP‑based notifications to URLs | Synchronous REST calls |
Delivery Model | Pub/Sub, real‑time & replay options | Pub/Sub, durable only | Point‑to‑point | Request/response |
Subscriber Options | APEX triggers, EmpAPI, external | Streaming API only | Endpoint handler only | n/a |
Transaction Control | Commit‑aware (with Publish After) | Commit‑aware | After record save | n/a |
Schema Flexibility | Fully custom fields | Fixed (fields on the tracked object) | Fixed XML schema | Depends on the external API |
Platform Events stand out by offering a fully customizable message schema, multiple subscriber patterns (including UI components), and built-in replay support for external clients.
Below are the screenshots of setting a new platform event:
Set up the required fields as per the requirement:
Publishing Events via Apex
Invoke it wherever it’s needed, for example:
Publishing Events Declaratively (Autolaunched Flow)
For a no‑code approach, use an Autolaunched Flow:
- Create an Autolaunched Flow
- Go to Setup → Flows, select New Flow, then Autolaunched Flow.
2. Add a Create Records Element
- Drag Create Records onto the canvas.
- Choose Specify object and fields, select your event (e.g. Order_Update_Event__e), and switch the filter to All Salesforce Objects if needed.
3. Map Flow Variables
- Define input variables for orderId, status, and comments.
- Map them to OrderId__c, Status__c, and Comments__c.
4. Activate
- Save and activate. Now, any time the flow runs, whether triggered by Process Builder, another Flow, or Apex via Flow. Interview will publish your event.
Publishing from an External Application
You can also publish Platform Events from outside Salesforce using the REST API:
1. Configure a Connected App
- In Setup → App Manager, create a Connected App with OAuth scopes that include Full Access and Streaming API
2. Authenticate
- Use OAuth 2.0 (Username–Password, JWT, or Web Server flow) to obtain an access token.
3. Send an HTTP POST
Publish your event by POSTing to
When to Use Platform Events
Platform Events excel when we need loose coupling (multiple independent subscribers), real‑time UI updates (EmpAPI in Lightning), event replay (durable subscriptions back‑fill), or high‑volume messaging (batch publish within limits). Typical use cases include order tracking, IoT feeds, audit logging, and orchestrating processes across orgs or systems.
Advantages
- Loose Coupling: Publishers and subscribers evolve independently.
- Scalability: Enterprise‑grade event bus supports high throughput.
- Multi‑Pattern Subscriptions: Apex triggers, EmpAPI, CometD clients.
- Replay Support: Durable subscribers recover missed events.
- Commit Control: “Publish After Commit” ensures events only fire on successful transactions.
Also Read – How to compress and extract zip files in Salesforce
FAQs
1. What are Salesforce Platform Events, and what problem do they solve?
Platform Events are a special type of event that allows you to publish and subscribe to custom notifications within Salesforce and from external systems. They solve the problem of real-time, asynchronous communication and system decoupling, enabling different applications or components to communicate efficiently without being directly dependent on each other.
2. How do Platform Events differ from Custom Objects?
Custom Objects are used to store data records, are queryable via SOQL/SOSL, and appear in reports. Platform Events, on the other hand, represent events or occurrences. They are not designed for data storage, cannot be queried, and are used for “fire-and-forget” asynchronous communication. Platform Event API names end with __e, while Custom Objects end with __c.
3. Can you give a simple real-world use case for Platform Events?
A common use case is real-time integration. For example, when a critical error occurs in an external billing system, that system could publish a Platform Event. Salesforce could then subscribe to this event and automatically create a high-priority case for the support team or notify a manager via a Slack message.
Conclusion
Platform Events transform Salesforce into a reactive, event‑driven platform. Whether we choose Apex, Autolaunched Flows, or external API calls, we will gain real‑time messaging, resilient integrations, and the flexibility to scale. Start by defining the event schema, pick the publishing approach that fits the team, and then build subscribers that react to those events, unlocking the power of event‑driven architecture in Salesforce. Happy Coding 🙂