Salesforce Platform Events: Explained

Platform Events exchange event data in real-time within the Salesforce platform, as well as between Salesforce and external platforms. Simply put, this is the way that Salesforce can broadcast when there have been changes made that these other modules/external platforms need to act on.

Platform Events are a Salesforce integration pattern (in other words, an integration capability) that use the Streaming API. In the spirit of “event-driven architectures”, they follow a Publish/Subscribe model (aka pub/sub) which reduces the number of point-to-point integrations required within your tech stack – reducing the need for an integration layer to connect Salesforce with external systems.

Platform Events speed up development. Not only are they faster to create than point-to-point integrations, but these modular components can be reused across different integrations. As Salesforce architectures become increasingly complex and sprawling, the traditional approach is not scalable, and will push Salesforce to its limits in terms of API calls.

What are Platform Events in Salesforce?

As mentioned above, Platform Events exchange event data in real-time within the Salesforce platform, and between Salesforce and external platforms. Platform Events are a Salesforce-native feature that work like this:

1. Event producer: An event producer creates an event.
2. Event bus: The event gets added onto the event bus (aka channel), which operates as a queue, with a strict chronological order, and executes each event one after the other.
3. Event consumers: Event consumers subscribe to an event. The moment that event gets put onto the event bus, the event consumer will be notified.

This approach reduces the dependencies between complex systems because the event consumer doesn’t need to know about the event producer; instead, the event consumer only needs to know about the event record, via the event bus.

Event consumers can consist of:

• Processes (flows, etc.)
• Apex
• CometD (the technology that the Streaming API is built on)

Below is a visual of how event producers function in a Salesforce platform context:

Salesforce Platform Events: Re-Explained

If you hear the buzz-phrase “event-driven architecture” in the context of Salesforce, going forward, you will know that this relates to Platform Events.

If you’re feeling out of your depth with the concepts we’ve just covered – don’t panic. I’m going to share an analogy (thanks to Priscilla Renwick) to explain how Platform Events work.

Some of us out there hate cooking – luckily, my partner loves cooking!

Say we go on holiday with two other couples. He is in the kitchen cooking, and the rest of us are all hungry. We’re in different parts of the house (maybe one at the pool, one upstairs), so we can’t talk to each other.

I am first to knock on the kitchen door: “Hey, is food ready?”, he replies: “No”. The next minute, our friend knocks and also asks: “Hey, is food ready?”, he gives the same reply. After some time, and especially if another friend comes knocking, his patience will be running out – he’s going to reach his limit.

Imagine that this is what is happening to Salesforce. If the person in the kitchen is Salesforce, and the friends are all different platforms, we could keep knocking on Salesforce’s “door” for updates. For example, external platforms need to know if there are any changes to Salesforce account records, so you can imagine them knocking on Salesforce’s door to ask: “Have there been any account changes?”, Salesforce is going to keep responding: “No, no… no”.

What my partner decided to do, instead, is create a WhatsApp group to communicate. He sent the link, saying that if we wanted to know when food is ready, we can join the group conversation. When the food was ready, he would broadcast that information out to us. It’s great for him because he’s not reaching his patience limit, and it’s good for us because we know straight away that dinner is ready without having to check multiple times.

This is the beauty of platform events. Salesforce is not reaching its limit in terms of API calls, and the external platforms will know straight away if any relevant changes to Salesforce data have happened.

In short, Platform Events are Salesforce broadcasting when there have been changes.

The Anatomy of a Salesforce Platform Event

Salesforce Platform Events are made up of the following components:

• Event bus: Operating as a queue, this is where events are added and broadcast in a chronological order (executing each event one after the other).
• Events: A change that needs to be broadcast (the event configuration includes fields and relationships).
• Event message: The notification that contains information about that specific event, i.e. data about what’s changed.
• Publishers: Internal/external apps that push events on to the event bus.
• Consumers: Can subscribe to events. The moment the event gets put onto the event bus, the event consumer gets notified.
• Window: A defined period of time.

Salesforce revamped a new event bus in 2020 due to the expanding platform portfolio – Tableau and MuleSoft were referenced as key drivers in making the decision. Check out this highly-informative guide on the evolution of the Salesforce event bus.

Salesforce Platform Events Example

Salesforce Web-to-lead is one of the most basic Salesforce features. Once upon a time, Web-to-lead would function in a very simple way – i.e. creates a lead record, which gets assigned to a user, and is converted to create records on other objects:

Web-to-lead is the catalyst to many other processes in Salesforce. Let’s take Order Management processes, as an example, with all the integrated systems it relies on during the end-to-end process (in dark blue):

Creating a single “create order” event will help to simplify this process “spaghetti”, i.e. again, Salesforce order management doesn’t need the other systems interacting with it to continually check for updates – Salesforce only needs to broadcast relevant changes, when they happen:

This is the ultimate dream scenario, when platform events are applied:

Where Are Platform Events in Salesforce?

Platform events are defined from Salesforce Setup (Navigate to: Integrations → Platform Events).

Platform Events are an example of a “Fire and Forget” integration, like outbound messaging, and have a similar look and feel to an sObject or a custom object.

When creating a Platform event, note the API name suffix ‘__e’, which makes it distinguishable from custom objects ( ‘__c’).

Publish Platform Events

Platform events are put onto the event bus by event producers, a process referred to as being “publishing”. Event publishing can be achieved:

• Declaratively (clicks) – Flows/Process Builder.
• Programmatically (code) – Apex. Use the Salesforce API to publish Platform Events from outside of the Salesforce platform.

This guide goes into more detail around how to publish a Platform event.

Subscribe to Platform Events

Platform events are executed by event consumers when events are put onto the event bus, a process referred to as “subscribing”. Event subscription can be achieved:

• Declaratively (clicks) – Flows.
• Programmatically (code) – Apex, LWC, Workbench. You can also use Python to subscribe to Platform Events from outside of the Salesforce platform.

This guide goes into more detail about how to subscribe to a Platform event.

Platform Events Are Immutable

Although Platform Events have the look and feel of an sObject (as we mentioned previously), the biggest difference is that Platform Events are immutable (they can’t be updated once published).

Platform Events + Salesforce DX

Platform Events and Salesforce DX are a match made in heaven. Salesforce DX encourages developers to create compact code bases that can be managed and deployed more easily.

Summary

Salesforce has invested in this technology, so it’s reliable, robust, and can do wonders for your architecture. Platform Events means you can exchange event data, in real-time, within the Salesforce platform, and also between Salesforce and external platforms.

This is the way that Salesforce can broadcast when there have been changes. Just like messaging all of your friends in a group chat when the food is ready, rather than being annoyed by each individual coming to ask – it unifies the information.