Flow Blog Series 05:
Platform Event Triggered Flow
In the first blog, we showed you why Flow is the way to go! There are 5 flow implementation types you can choose from, but no stress! In this blog series you will find out which one you can use best in what scenario. Let’s go with the Platform Event-Triggered Flow!
Platform Event Messages
Since the summer ’20 release, only running instances of a Flow could subscribe to platform event messages. Now, users can trigger a Flow when a platform event message is received. Unlike Process Builder, users can access all available records when a Flow is invoked by the platform event message.
Don’t forget to subscribe!
Platform events make the process of communicating changes and responding to events more easy. Publishers and subscribers communicate with each other through events. One or more subscribers can listen to the same event and carry out actions.
With an Event-driven architecture each service publishes an event whenever it updates or creates data. Other services can subscribe to events. It enables an application to maintain data consistency across multiple services without using distributed transactions.
What does it look like?
Here an example of order management. The order management app creates an order in a pending state and publishes an order created event. The service department receives the event and attempts to process the order. What happens next, is that it publishes an order update event. The order update service receives this event. The state of the order can be changed to approved, canceled or fulfilled.
The platform event structure is shown in the diagram.
Let’s make it visual!
We will be showing how to publish an event by flow, and how to create a platform event consumer.
Flow Blog Series
Yeah! You know the way to go with that Platform Event-Triggered Flow now. Read more blogs and find out about other flow types too.