Creating a Custom Notification Flow that responds to a Platform Event
Process Builder has been able to subscribe to Platform Events for a while now, and one of the most useful applications of this is Custom Notification Flows, which are flows that notify target recipients that an event has occurred.
Some Salesforce services are starting to fire platform events when errors occur, intended to be intercepted by Process Builder and handed off to Lightning Flow for emailing, SMS, Chatter posting and more.
In this example, we’ll show how an error generated in Salesforce’s new Next Best Action service can be handled in this way.
The Basic Documentation
The main documentation for this feature is here, and the release note describing it is here.
The First Wrinkle: Configuring the Object Query
When you configure a trigger in Process Builder, you are always asked to select an Object and a Criteria expression that must be true in order for the process to run:
This can be confusing. Like the fields in Flow Screens, platform events are not inherently linked to a particular object. Depending on how they’re setup, they might feel very object centric, or they might not have anything to do with objects. Here are two equally legitimate platform events as examples:
| Name | AccountExpirationDateReached |
| Payload Fields | AccountId, ExpirationDate |
Platform Event 2
| Name | AlexDrankSomeCoffee |
| Payload Fields | Brew Strength, Hyperactivity Level |
The first Platform is pretty clearly tied to a particular Account, but the second one is not.
In order for Process Builder to trigger on a platform event, is is NOT SUFFICIENT that the event be subscribed to. It is ALSO NECESSARY for the Matching Conditions to return ONE and ONLY ONE result. If they return more than one or zero, the event will be ignored:
IF the platform event payload contains a recordID, this is a pretty logical, straightforward process. For example, here, the platform event arrives with an AccountId. It’s a simple matter to use that in Matching Conditions like so:
If you’re working with a platform event that is not oriented around an object, things can get a little strange. In the example of our AlexDrankSomeCoffee platform event, we want to run a process every time this event gets fired, but which Object do we pick? None of these objects are particularly related to this event:
Well, we have to pick something to proceed, so suppose we pick Account again. That’s ok up until we get to the event payload, when we have nothing we can select that will produce the necessary ONE and ONLY ONE result:
The good news is that if you can craft a Matching Condition that returns one and only one result, it does not matter if it is unrelated to or only tangentially related to the event.
One way to do this is to use the Created By ID, which is present on all Platform Events. Set the Object to User and set up the Matching Conditions like so:
If you tried to put this into English, it would be something like “Process incoming platform events of type Platform Status Alert Event only if there’s one and only one User in this Salesforce Org that has the same User ID as the User who ’caused’ the event.” If that sounds strange to you, you’re right. But the good news is that using a dummy Matching Condition like this, you can build Process Builder triggers that trigger on every instance of a platform event that is not tied to a particular object.
The Second Wrinkle: Platform Event Payload Can Only Be Accessed in Certain Places
We’ve created a Matching Condition that successfully intercepts 100% of our platform event. Now we want to do something with the payload. Let’s use as an example the Platform Status Alert Event that Next Best Action strategies fire when they hit an error. We want to take the error information and Post it to a Chatter Group and then send it in an Email.
Like any good error alert, there’s a lot of useful information: No less than 15 useful pieces of payload. And Process Builder has built in actions for both Posting to Chatter Group and Sending Email. In the screen shots above, you can see how Matching Conditions lets us pick and choose from the fields of the platform event payload. We might expect to find the same thing in Post to Chatter, but we don’t:
And you can’t use any of Process Builder’s built-in tools, like Email Alerts, to make this work either.
To work around these limitations, use your Process Builder to launch a Flow. Importantly, you can pass some or all of the payload to a Flow. Once there, Flow can use all of those values in the body of Chatter posts and the subject line of outbound emails, and more.
To demonstrate this, I’ve created a new automatic (“autolaunched”) flow called Custom Notification Flow and activated it:
…and I’ve added a Launch Flow action to the trigger process.
We’re making progress, but all is not yet right. One symptom of the remaining wrinkle is that when I go to add information from the payload to the Subject line of my email, the payload is still nowhere to be seen:
So now we come to our third wrinkle.
The Third Wrinkle: You Need to Manually Create Flow Resource Variables to “Catch” the Incoming Payload Data
A flow can handle incoming data that’s passed to it when it starts, but each piece of data has to be temporarily stored in a variable resource. (A video on the use of variable resources can be found here). In our scenario, we need to create a string variable for each incoming platform event field and click on the “Available for input” checkbox to make the variable available on the ‘outer surface’ of the flow to catch the incoming platform event field value (Requiring you to explicitly opt-in the variables that you want to expose outside of your flow is a security feature).
We’ll continue to focus on Platform Status Alert Event, so let’s create some variables in our Flow to catch the various payload fields we care about. As you’ll see shortly, once these are created, Process Builder will detect them and start making them available for use.
This image from the doc page shows the different fields in the payload:
Let’s start with ‘Subject’. That appears to be where the most evocative error information will be found. To access this, we’ll need to create a variable with a similar name:
We save and our modified flow and (importantly) activate it so it’s the latest flow. We then edit our process builder, adding a new Launch Flow action, and again selecting the Launch Flow action. This time, because our active version of this flow has a Subject variable defined and “Available for input”, it gets detected by Process Builder and is available for configuration:
When we select the Subject variable, Process Builder lets us select a payload field to pass into (map to) the Subject flow variable:
I’ll repeat this process to enable a few more of the payload fields to be passed into the flow.
Let’s fast forward to where all of the variable resources have been defined in Flow:
…and all of them are visible in Process Builder:
We now create the mappings that will send the event payload fields to the appropriate Flow input variables:
Wrinkle 3a: If you don’t see the variables showing up in Process Builder, you may just need to wait: Sometimes it can take as much a 1 day for them to show up due to a caching bug. Other common reasons: Failure to click “Available for Input”; Failure to create variables of type “Text”.
Working with Event Payload Inside of Flow
At this point, we’ve done the heavy lifting and now can get the event payload through Process Builder and into Flow. Now we can start to have fun. First we’ll create a Text Template that will allow us to merge values from the event payload into a single string that can be used as an email or sms body.
We’ll then pass this text template in to the Send Email action as the value for the Body:
And we’ll also use it in the Post to Chatter flow action:
Testing Our Custom Notification Flow
To test this, we’ll start with a working NBA Strategy:
This strategy makes use of a custom field called CSAT__c:
And we’ll deliberately introduce an error by changing the name the custom field to CustomerSat__c. That’s the kind of thing someone might do without realizing it would break running decisioning strategies.
The next time someone runs our NBA Strategy, it will crash because the CSAT__c field no longer exists. Let’s do that by refreshing our Case page. Sure enough, the error appears. By design, the specifics of the error aren’t exposed to the unfortunate user who was the first person to stumble across it:
But in the admin’s inbox, the error is waiting:
and it’s also in the desired chatter feed:
Other Notification Tools
In addition to the built-in Email and Chatter flow actions, you might want to explore this SMS flow action, which makes use of Twilio.
