What Is a Platform Event-Triggered Flow?

What Is a Platform Event-Triggered Flow?


Admins, have you ever needed to have actions taken in Salesforce if something happens in an external system? Have you ever needed to log an error or notify people if an error occurs? If yes, then a platform event-triggered flow might be what you need.

In this post, we’ll provide a high-level overview of a platform event-triggered flow, share use cases solved with a platform event-triggered flow, and give you an example platform event-triggered flow to inspire you to build your first one.

Salesforce event-driven architecture showing publishers and subscribers to the event bus.

Publishers send the event messages to the event bus. There are subscribers, who are listening for the event messages and, once received, will in turn do something. Flows can be subscribed to platform event messages. When platform event messages published through Apex, APIs, flows, and other processes are received, this will launch the platform event-triggered flow.

Imagine if your smartwatch was malfunctioning and it could send a service alert to the company to send you a replacement. How cool would that be? The smartwatch would be the publisher in this case. The company is the subscriber to look for a maintenance alert event message. Once received, it would prompt a new watch order to be processed, if within the warranty period, or will send an email to the customer with a discount for a new watch purchase if outside of warranty—which would be the process handled by your platform event-triggered flow.

To create a platform event-triggered flow, select Platform Event-Triggered Flow from the New Flow menu in Setup.

Platform Event-Triggered Flow selected as a flow type on the New Flow screen in Setup.

What are example use cases solved with a platform event-triggered flow?

There are many use cases that are solved with a platform event-triggered flow. Here are a few examples.

  • When a person’s blood pressure monitored by a device is deemed dangerously high, a case is created for the nurse to contact the patient.
  • When an appliance is detected to be in need of maintenance, an alert is added to the account for the customer service rep, and the customer is sent an email.
  • When a printer is low on toner, a toner order is submitted on behalf of the customer.
  • Create an error log record whenever a screen flow fails (and the error isn’t handled by a fault path).
  • Send a notification to a user or group of users when a specific event occurs.
  • Update a record when a platform event message is received.
  • Create a task or event when a platform event message is received.

How do I get started?

Fight the inclination to go into Salesforce and start building in Flow Builder. It’s important to understand the requirements and overall process, and to do your analysis BEFORE you start building your automation. I recommend sketching it out and validating the process with business stakeholders before you log in to Salesforce and go to Setup. It’s much easier to make changes on paper (or electronically) than to have to reconfigure a flow.

Remember, you’re automating manual steps, so think about which actions you take that you need to tell Salesforce to do on behalf of the user, including making decisions. If you search for open cases and find some, now what do you do? What if you search for open cases but don’t find any? This process map becomes your guide to building your automation.

Can you show me an example of a platform event-triggered flow?

If you’ve never seen a platform event-triggered flow, you probably want to see some examples. I have two!

Our first example is for an espresso machine company to automate the proactive maintenance of their espresso machines. When an espresso machine has an issue, it will notify the company of the issue and, based on the type of issue, the company will take action accordingly.

This platform event-triggered event fires (1) when an Espresso Machine Maintenance platform event is received. (2) We use the Decision element to determine the maintenance reason. (3) If the maintenance reason is urgent, then we’ll create a high priority maintenance case using a Create Records element. (4) For all other maintenance reasons, we use a Get Records element to get the asset name using the asset ID from the platform event. (5) We use another Get Records element to get the account name using the account ID from the platform event. And lastly, (6) we use a Create Records element to create the task for the account owner to follow up.

Espresso Machine Maintenance platform event-triggered flow.

Before you create your platform event-triggered flow, you’ll need to create your platform event. Creating a new platform event is, in a way, very similar to creating a new custom object.

Platform Events page in Setup, where you create a new platform event.

We’ve already created the Espresso Machine Maintenance platform event. This platform event has three custom fields shown below to capture the Account, AssetId, and Reason. These are the fields that can be referenced in the platform event-triggered flow.

Espresso Machine Maintenance platform event setup.

Our second use case is to resolve the common dreaded MIXED_DML_OPERATION flow error that occurs when a flow tries to create or update a Setup object (that is, Users, Groups, Permission Sets, Queues, and Territories) and Non Setup object (all other objects). One way to resolve this is to replace the steps to create or update the other object with a Create Records element for a platform event. Then, create a platform event-triggered flow that performs the create or event of the other object.

Salesforce MVP Michelle Hansen ran into this use case while streamlining user creation at her company. When a new user case is created, a record-triggered flow should create the user and close the case. However, this caused a Mixed DML error when the record-triggered flow ran because her flow tried to create a user record (Setup object) and update a case record (Non Setup object). To resolve this, she created a platform event called “User Created/Edited”, moved the case update to a platform event-triggered flow, and added a Create Records element in the record-triggered flow to create a User Created/Edited platform event containing information to close the case. The platform event-triggered flow is triggered (1) when a User Created/Edited platform event is received. (2) It uses an Update Records element to update the new user request case with information to close it. Check out Michelle’s Automate This! — Resolve Mixed DML Errors with Platform Events blog for a deep dive into how she built this solution.

User Created/Edited Platform Event-Triggered Flow.

What should I keep in mind when working with platform events?

Here are a few things you should know about platform events or platform event-triggered flows.

  • The $Record global variable in a platform event-triggered flow contains the field values from the platform event message in a platform event-triggered flow and users can use those values throughout the flow.
  • Avoid creating an endless loop in an event process by ensuring a new event message’s field values don’t meet the filter criteria for the associated criteria node.
  • Each platform event-triggered flow or resumed flow interview is executed asynchronously in a transaction distinct from the transaction that published the event message.
  • Debug logs for platform event-triggered flows and resumed flow interviews are displayed under the Automated Process user.

For additional considerations, read Considerations for Subscribing to Platform Events with Processes and Flows.

Roll up those sleeves and build your first platform event-triggered flow!

I’m sure you’re now inspired by the examples and have ideas for how you can use a platform event-triggered flow in your org. No better way to learn than by doing! So, roll up those sleeves and get into a personal Dev org or sandbox and give this a spin. Test it out with a simple use case.

As an admin best practice, please build and test your automation first in a sandbox and never directly in production.


What Is a Schedule-Triggered Flow?

What Is a Schedule-Triggered Flow?

As an admin, you may be given business requirements to perform some type of automation, like maintain your org’s data or complete routine tasks (for example, send an email reminder) on a scheduled time and frequency, such as daily or weekly. Or, you might just need to run automation once on a batch of records. […]

Cloudy outside holding a laptop next to text that says, "What Is a Screen Flow?"

What Is a Screen Flow?

As an admin, there may be times where you want to simplify the process of gathering data from your end users by improving the user experience. This involves minimizing the number of screens and clicks needed to get the job done and increasing the overall efficiency of the process. You want to flex those declarative […]

Cloudy surrounded by greenery and text that says "What Is a Subflow?"

What Is a Subflow?

Ever find yourself building the same automation steps to solve different use cases, which results in slightly different flow solutions? So now you have clones of the same automation steps hanging out in multiple flows. And then, goodness forbid you have to make a change to those steps in all those flows? That can be […]