Platform Events in Flow

Module 5 of 6 in the chapter The Admin’s Integration Toolkit, chapter 4 of the Integration Architect course. Each module stands on its own. Previous: Who’s Calling In · Next: What You’ll See When It Breaks

The question this module answers: How does a flow tell other systems that something happened, without calling any of them?

In modules 1 to 3, the flow called the other system. It needed the address, the named credential, the right request, and a plan for the answer. That’s request and reply: you ask, and you wait.

Sometimes you don’t need an answer. A delivery is running late, and Redrock, the customer team and the warehouse all want to know. You could call each one. Or you could say it once, out loud, and let whoever cares pick it up. That’s a platform event. As I put it in class: fire and forget. Once the event goes out, you’re done. You move on.

Define the Event

First, define the message. From Setup, go to Platform Events and choose New Platform Event. Steve Trucking’s is called Delivery Update.

It looks like an object, but it’s not. Its API name ends in __e, not __c: Delivery_Update__e. You add fields to it the way you would to an object: a Delivery Number, a Status, a New ETA.

But only some kinds of fields. Salesforce allows checkbox, date, date/time, number, text and long text area (Platform Event Fields (opens in a new tab), Platform Events Developer Guide, checked 2026-11-01). No picklists, no lookups, no master-detail. That’s on purpose. This event is going to leave Salesforce and go to other systems, so it needs to survive on its own outside of Salesforce. A lookup means nothing to Redrock. A delivery number does.

Publish It From a Flow

Publishing is a step you already know. In Salesforce’s words: “add a Create Records element to the appropriate flow. Where you’d usually pick an object to create, select the custom platform event” (Publish Event Messages with Flows (opens in a new tab), checked 2026-11-01).

So Steve Trucking adds a record-triggered flow on the delivery: when the ETA moves later, create a Delivery Update with the delivery number, the status and the new ETA. Save, activate, done.

Look at what’s missing. No address. No named credential. No fault path for Redrock being down. When a flow publishes onto the event bus, all of a sudden it doesn’t need the connection, the credential or the error handling. Those are now the listener’s job.

One setting to choose on the event itself: when it goes out.

• Publish Immediately is the default, and Salesforce recommends it for most events. The event goes out when the flow publishes it, “regardless of whether the transaction succeeds.” So a listener can sometimes get the event before the delivery record is saved.
• Publish After Commit waits until the record is saved, and isn’t published at all if the save fails. Salesforce’s advice: choose it “only if the subscriber requires committed transaction data.”

If Redrock will call back to read the delivery when it hears the event, choose Publish After Commit, so the delivery it reads is the one that was saved.

One Event, Many Listeners

Now, who hears it?

Inside the org, a flow can listen. Create a platform event–triggered flow, and in its Start element choose the Delivery Update event. The event’s fields are in $Record, the same way a record’s fields are in a record-triggered flow (Subscribe to Platform Event Messages with Flows (opens in a new tab), checked 2026-11-01). Steve Trucking’s tells the customer team that the delivery is late.

A flow that’s already running can listen too. Add a Pause element, choose the event, and set which values it waits for: this delivery number, say. When a matching event arrives, the flow picks up where it stopped.

Outside the org, Redrock’s system can listen. It subscribes to the event through the Pub/Sub API, signing in through its External Client App as its integration user, from module 4.

Click to enlarge

One event, many listeners.

Notice which way Redrock’s arrow works. The event goes out to Redrock, but Redrock is the one that connects in. If I want to send a package to you, I could find your address, put it in a car and drive it to your house. With an event, it’s the other way around: you drive to my house, say “I’m here,” and I hand you the package. So Redrock does the driving, the reconnecting and the error handling. Salesforce just hands over what’s waiting. That’s why so many people draw this arrow the wrong way. Chapter 11 takes it apart.

And the publisher doesn’t need to know who’s listening. The flow that publishes Delivery Update doesn’t know about the customer team’s flow or Redrock. One admin can write the publisher this year, and another can add a listener next year. They never have to coordinate. That’s loose coupling, and it works inside the org as well as out: one flow publishes an error event, and one central error-handling flow listens to it, instead of every flow calling it as a subflow.

How the Listening Flow Runs

A platform event–triggered flow isn’t part of the save that published the event. Salesforce lists what that means (Subscribe to Platform Event Messages with Flows (opens in a new tab)):

• It runs later, on its own. Each one “runs asynchronously in a separate transaction from the transaction that published the event message.” There can be a delay. That’s also why a separate transaction gets its own limits.
• It gets events in batches, up to 200 at a time, in the order they were received.
• It runs as the publisher. Its debug logs are under the Automated Process user, “but each flow interview runs in the context of the user who published the event message.” If it creates a record, the record’s Created By is the user who published.
• Nothing tells you if it never starts. “If an event fails, the flow doesn’t start. Because the flow is never triggered, a flow error email isn’t sent.” Look at the event’s errors instead. More on that in the next module.
• No order between listeners. If several flows listen to the same event, Salesforce can’t guarantee which one handles each event first. Don’t build one listener that depends on another having run.

What Goes in the Event

This is a very basic question, and every event designer meets it: what do you put in the event?

Think of the event as a package. The package is only so big. If you can fit everything in it, ship it: the delivery number, the status, the new ETA, the customer, the stops. Redrock can act on it as soon as it arrives, without spending API calls coming back to Salesforce. The downside is that a package can sit and wait. If Redrock’s system is down for twelve hours, the ETA in the package may already have changed when Redrock reads it.

If it doesn’t fit, or if it has to be fresh, send just the ID. The event only says that something happened: delivery D-1042 changed. Redrock calls back, through the REST API, and gets the delivery as it is now. That’s fresh, and it costs a call.

Click to enlarge

The whole package or just the ID.

Neither is wrong, and you can mix them: carry the few fields most listeners need, and the ID for the rest. And if listeners call back, remember the publish setting above: Publish After Commit, so there’s a saved record to read.

What Chapter 11 Adds

This module is the admin’s half. Chapter 11 is the rest: the event bus itself, the Pub/Sub API, how a listener that was away catches up, how long events are kept, how many can go out to other systems, Change Data Capture, and what happens when the event bus meets other companies’ event buses.

What an Architect Decides Here

• For each change other systems care about: an event, or a call. Do you need an answer, or just to say it happened?
• Each event’s fields: what a listener needs to act, and whether it can survive outside Salesforce.
• The whole package or just the ID, and what that costs the listeners.
• Publish Immediately or Publish After Commit, for each event.
• Who listens to each event, inside and outside the org, and who owns each listener. Write it down: the publisher can’t tell you.
• How you’ll know when a listening flow never ran.

Beyond the exam: what AI changes. An agent that can run a flow can publish an event, and everything listening will react, inside the org and out. The publisher doesn’t know who’s listening, and neither does the agent. So the list of events and their listeners matters more, not less: it’s how you know what one action by an agent will set off. And AI is good at drafting that list from your org’s flows, if a person checks it.

Explore

• Platform Events Developer Guide, Publish Event Messages with Flows (opens in a new tab) and Subscribe to Platform Event Messages with Flows (opens in a new tab), checked 2026-11-01.
• Platform Events Developer Guide, Platform Event Fields (opens in a new tab): field types and publish behavior, checked 2026-11-01.
• Chapter 11, Events and Asynchronous Integration: the event bus, in full.