One of the most common integration requests in Salesforce goes like this:
"When an opportunity is closed won, tell the ERP. And the provisioning system. And the data warehouse. Oh, and the partner portal."
The traditional answer is to write callouts from Salesforce to each system. It works for a while. Then one of those systems is slow, another changes its API, and a third is down during a release. Suddenly a simple save in Salesforce becomes fragile.
Platform Events offer a much cleaner answer.
What Platform Events Are
Platform Events are Salesforce's native way of publishing and subscribing to business events. You define an event, like Order_Shipped__e, with the fields it needs. Publishers send events to the Salesforce event bus. Subscribers, inside or outside Salesforce, receive them and react.
The key benefit is decoupling. The publisher does not know or care who is listening. New subscribers can be added without changing the code that publishes the event.
Who Can Publish and Subscribe
Publishers can be:
- Flows and Apex inside Salesforce
- External systems via Salesforce APIs
Subscribers can be:
- Apex triggers and Flows inside Salesforce
- External applications using the Pub/Sub API
- Integration platforms such as MuleSoft
Platform Events vs Change Data Capture
Both are event-driven, so people often confuse them.
- Change Data Capture publishes events automatically whenever records change. It answers "what changed in the data?"
- Platform Events are custom events you define and publish deliberately. They answer "what happened in the business?"
If downstream systems only need to mirror data, Change Data Capture is often simpler. If they need meaningful business signals, like "order approved" or "customer onboarded", Platform Events are usually the better fit.
Design Tips From Real Projects
Model business events, not technical ones
"Contract_Activated" is far more useful to subscribers than "Record_Updated". Good event names describe something the business recognizes.
Keep payloads purposeful
Include what subscribers genuinely need. Too little forces callbacks. Too much creates hidden coupling and potential data exposure.
Make subscribers idempotent
Events can be delivered more than once. Subscribers must handle duplicates safely.
Understand replay and retention
Subscribers can replay recent events after an outage, but events are only retained for a limited period. Design recovery processes with that window in mind.
Watch your allocations
Platform Events have publishing and delivery allocations. Estimate volumes early, especially for high-frequency events, and monitor usage.
Think about publish behavior
Decide whether an event should be published immediately or only after the transaction commits. Publishing before a rollback can announce something that never actually happened.
When Not to Use Them
If the caller needs an immediate answer, such as checking credit before saving a record, a synchronous API call is the right tool. Platform Events are for announcing, not asking.
Final Thought
Platform Events let Salesforce announce what happened, and let the rest of the enterprise decide how to react. That one shift can turn a fragile web of callouts into a calm, extensible architecture.