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.
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.
There are many use cases that are solved with a platform event-triggered flow. Here are a few examples.
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.
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.
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.
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.
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.
Here are a few things you should know about platform events or platform event-triggered flows.
For additional considerations, read Considerations for Subscribing to Platform Events with Processes and Flows.
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.
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. […]
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 […]
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 […]
