Platform Events are a great tool to add to the admin's toolkit, but they take a moment to wrap your head around. And for those of us that are declarative-only, their strong scent of "developery-ness" adds to the wariness. But once you break them down, they can be pretty handy!
Back in October 2023, six years after first encountering the idea of platform events (on Trailhead), I rediscovered them and then wrote about them. Since then I've learned some things, sometimes the hard way.
Definition
Before you go back and read that earlier post (which you should, but maybe after you finish this one!), here's the quick download on platform events:
They're a tool "to connect business processes in Salesforce and external apps through the exchange of real-time event data."
That second clause reminds us that platform events are generally used for integrations.
But they don't have to be an integration to an external system, they can connect processes within Salesforce, which is what I'm interested in.
Platform events can have fields, like records do. So you can use them to transmit information between the processes you're connecting. (More on that later.)
But unlike records, platform events do not persist anywhere. They get "published" to any processes that are listening ("subscribed") and then they disappear, leaving little or no trace behind.
Platform events go out more-or-less instantly from your process that publishes them. However, the publishing is technically asynchronous.
Because platform event processing is asynchronous, any processes that are kicked off by a platform event are outside of the transaction that published the event, so those processes get their own set of Salesforce limits.
Limitations and Learnings
I hadn't picked up on all of those initially, so that's why I wanted to share with you.
[This one actually isn't new to the discussion at all, but it's worth repeating:] Platform events do not persist. If you want to see that an event fired, you're going to have to take some measure of your own, like have a platform event-fired flow create a Chatter post, or a Task, or a log record. (I create log records using My FlowLog Object.) Otherwise, platform events are like something shouted: If you heard it, great. If not, the sound is gone.
Platform event-triggered flows can't call subflows. I don't really know why not, but they can't. (Mostly this is a minor annoyance, since you could rebuild the functionality of what would have been the subflow within your PE-triggered flow.)
I am told* that if you have a batch process that publishes platform events in a batch, flow will also process those events in a batch, not singly. (Which was how I understood it to work.) Apparently in a platform event-triggered Apex class you can set a batch size for processing. But in flow you cannot. So when I built a process that fired a platform event every time a record of my holding object was created and then bulk imported into that object (using Apsona) I didn't realize that my platform event processing flow would take things in batches since the events were fired in batches. [There's a workaround that I'll write about in my next post.] That lead to errors and to me being very confused by those errors..
* Intentional passive voice there. I can't find documentation to point to. I certainly experienced this, so I believe it to be true. And while the person that explained this probably wouldn't mind if I mentioned them, I am going to let this be my own writing and take personal responsibility if I've gotten it wrong.
You can build a platform event-triggered flow to run in system context (it runs as the Default Workflow User) or as the user that triggered the publishing of the platform event.
But either way, as I understand the note here, "if a flow interview creates or updates records, system fields like CreatedById and LastModifiedById reference the user who published the event message." I found that both a little surprising but also quite useful. It means record creation/processing is less anonymous than it might otherwise have been.
I am also told that it's possible (though extremely rare) for a platform event to be missed by the subscribing process. This, in combination with the fact that platform events don't persist anywhere, means that you probably want to avoid storing data on the platform event that wouldn't otherwise be reproducible.
For example, I was recently working on a process by which a user will import thousands of records from an outside system. The records go onto a holding object that has, say ten fields. The holding object records are then processed by a flow into several related records, based on the values in those fields. (Similar to how the NPSP Data Importer works to take in a row of person, account, and donation data and turn that into contact, accounts, opportunities, and campaigns.) I asked some questions on MVP Office Hours and, at one point, someone suggested that perhaps instead of uploading into the holding object, I should just upload as platform events directly, with fields on the platform event for all the data, like I have on the holding object right now. I didn't even realize that it was possible to directly upload platform events (directly publish them)! But even if I had known that, a few things would worry me about that approach:
If the platform event were missed, it would be like it had never happened and we would have no way to know. Even if this is a one in a billion case, it worries me.
If the flow picks up the publishing of the event, but then errors, I would have no way to see the data that needs reprocessing or how far it got before failing. We would have to go back to the spreadsheet that was being uploaded and figure out which ones didn't process properly. That seems burdensome.
It would be very challenging to build, test, and debug the processing of the platform event into the related records because I couldn't see what was going on. (Maybe that's just me. I need to see the process as it moves step-by-step.)
Note also the distinction in platform events between Publish Immediately and Publish After Commit. It's a subtle difference that I'm not sure I entirely understand. But "immediately" means that your publishing action (such as a Create Records within a flow) always publishes, even if the flow proceeds to fail and roll back the transaction. That could mean that an event fired referencing a record that proceeded never to have existed. So make that choice carefully when defining the platform event or you could run into trouble later on.
More to Come
My next post is going to be a full description of what I recently built using platform events. Watch this space!