Platform Events: The Hidden Infrastructure Behind Real-Time Business Operations

Say an order system in Salesforce needs to tell a warehouse app, a billing service, and a customer notification flow that an order just shipped. You could have Salesforce call each system in turn and handle every failure along the way. Or Salesforce could announce “order shipped” once and let each system that cares pick it up. That second model is what Platform Events give you.

They are a good fit for a lot of integration work. They are also easy to oversell. The part most explainers skip is what the event bus actually promises, and that is where the real design work lives. We will cover the basics quickly and spend most of our time there.

What a Platform Event Is

A platform event is a message with a defined shape. You define a custom platform event the same way you define a custom object: give it a name and add fields. Publishers send event messages, and one or more subscribers can listen to the same event and act on it. The publisher does not need to know who is listening.

Two practical notes before you plan anything. Platform events are available in Performance, Unlimited, Enterprise, and Developer Editions, and they are not supported in Professional and Group Editions. And event messages are not records you can browse: you can’t query them with SOQL or view them in the UI.

Publishing: Flow, Apex, or an API

Inside Salesforce, you publish with Flow or Apex. External apps publish through Salesforce APIs. Older material also lists Process Builder, but Salesforce no longer supports Workflow Rules and Process Builder as of December 31, 2025, so build new publishers in Flow or Apex.

Each event definition has a publish behavior, and it matters more than people expect. With Publish After Commit, the event goes out only if the transaction that published it commits, and you can roll it back with a savepoint. With Publish Immediately, the event doesn’t respect transaction boundaries and can’t be rolled back. If your “order shipped” event fires and then the transaction fails, Publish Immediately means the warehouse hears about a shipment that never got saved. Publish After Commit is the safer default for anything tied to a record change. Publish Immediately fits cases where the event must go out whether or not the transaction commits, such as recording that something failed.

Also know what a successful publish call means. In Apex, a successful EventBus.publish result means the publish request is queued and the message is published asynchronously. It is not confirmation the event reached the bus. To get the final outcome you implement an Apex publish callback.

Subscribing: Inside and Outside the Org

You can receive platform events in flows, Apex triggers, Pub/Sub API, or CometD clients. Salesforce can also deliver events to event relays, which pass them on to systems outside Salesforce.

Flow. A platform event-triggered flow starts when a message arrives. Flows receive up to 200 messages per batch and run in a separate transaction from the publisher.
Apex triggers. An after insert trigger on the event. It runs asynchronously in its own process, with a default batch size of 2,000 messages, under the Automated Process user unless you configure another one.
Pub/Sub API and CometD. This is how an external system listens. Something has to run that client, whether it is your own service or an integration platform. Platform events reduce the plumbing between systems; they do not remove the need for a subscriber on the other side.

What Salesforce Guarantees, and What It Does Not

This is the section to read twice. A lot of content about platform events, including an earlier version of this post, describes them as guaranteed delivery with no retry logic needed. That is not what Salesforce documents.

Retention is 72 hours. High-volume platform event messages are stored for 72 hours. The 24-hour figure you may see applies only to legacy standard-volume events, and new custom events have been high volume by default since API version 45.0. Salesforce doesn’t guarantee storage beyond that window.

Delivery is not guaranteed. Events are held in a distributed system that, in Salesforce’s words, doesn’t have the same semantics or guarantees as a transactional database. Publishing is asynchronous, and in rare cases a message is never persisted. When that happens, the event is not delivered to anyone and can’t be recovered.

Duplicates are possible. Publishing uses an at-least-once model, not exactly-once. If Salesforce retries a publish internally, the same event can land twice: same EventUuid and payload, different replay ID. Salesforce’s own recommendation is to handle duplicates in your subscriber.

Order is limited. Events in a single publish call keep their order, but events published across different requests aren’t guaranteed to arrive in order.

Replay IDs have rules. Each delivered message carries a replay ID marking its position in the stream. Replay IDs aren’t guaranteed to be contiguous, you must not compute one from another, and they aren’t guaranteed unique across maintenance such as an org migration. On rare occasions an org move can reset the retained stream entirely.

What Your Subscriber Has to Do

Given those rules, a production subscriber needs four things.

Track the last replay ID you processed. A Pub/Sub API client stores the replay ID of the last processed event and resubscribes from it after a disconnect. The ManagedSubscribe RPC, in beta, can store that position on the server for you.
Process idempotently. Because duplicates happen, deduplicate on EventUuid or key your writes on a business ID, so handling the same event twice changes nothing.
Handle errors inside Salesforce subscribers. In an Apex trigger, an uncaught exception stops the rest of the batch. You can set a resume checkpoint or throw EventBus.RetryableException to retry. A trigger that runs out of retries goes into an error state and stops receiving events until someone fixes it, and Salesforce emails you when that happens. Someone should be reading that inbox.
Plan for the gap. If a subscriber is down longer than 72 hours, or an event is lost, replay will not save you. For anything financial or customer-facing, pair events with a scheduled reconciliation job that compares the two systems and fixes drift. We walk through a real example of this backstop in our post on Change Data Capture in practice; the same pattern applies here.

None of this is exotic. It is the same discipline any message-based integration needs. The mistake is assuming Salesforce does it for you.

Allocations and Monitoring

Platform events are not unlimited. There are allocations for event definitions, publishing, and delivery to Pub/Sub API, CometD, empApi components, and event relays, and they vary by edition and add-on license. Check the current numbers for your org on that page rather than trusting a figure in a blog post, including this one. If you need more delivery capacity, Salesforce sells an add-on.

To see where you stand, query the PlatformEventUsageMetric object for publishing and delivery usage. Inside Apex, publishing also counts against governor limits: a Publish After Commit call counts as one DML statement, and Publish Immediately calls have their own limit of 150 per transaction.

When Platform Events Make Sense

We reach for platform events when one change in Salesforce needs to reach several consumers, when those consumers should not slow down the user who made the change, and when a short delay is acceptable. Decoupling the publisher from its subscribers is the real benefit: adding a fourth consumer later does not mean touching the code that publishes.

We are more cautious when the business needs a hard guarantee that every message arrives exactly once, or when the “integration” is really one system asking another a question and waiting for the answer. A direct API call or a middleware platform with its own delivery guarantees can be the better fit there. Platform events can sit alongside middleware rather than replace it.

The design work is the same either way: decide which business moments deserve an event, pick the right publish behavior, and build subscribers that expect duplicates, track their position, and have a backstop for the day something goes quiet. If you are weighing platform events for an integration, we are happy to talk it through.