I was wondering, what are scenarios that are dedicated to use Platform Events? Documentation says for example - integrations between Salesforce and other external systems. But, I was participated in a lot of projects where they were used very rarely and in fact all of the business logic, integrations, etc. can be implemented using directly automations, triggers, webservice callouts etc.

Are there any scenarios where platform events are the only option to choose from? Or it is in most cases just an another tool to use?

  • 1
    Key Takeaways from architect.salesforce.com/decision-guides/event-driven are the answer to this question, specifically these two bullets: 1) For near real-time integrations, prefer approaches that use event-driven architectures and 2) High-volume platform events and Change Data Capture (CDC) are the preferred mechanisms for publishing record and field changes that need to be consumed by other system
    – identigral
    Nov 4, 2023 at 19:12

5 Answers 5


Take the scenario where Salesforce needs to publish an event when a certain thing happens.

Salesforce announces - as the Publisher in the Pub-Sub system - that something happened, and this event includes information from multiple sources within Salesforce (multiple objects, for example).

In this scenario, you can't use Change Data Capture, which also implements the Pub-Sub approach, because you need to publish data from different sources. You could use an Apex trigger to catch the last meaningful DML and then call a SOAP or REST service from an asynchronous execution branch (a queueable or a batch). Now think about the cost of doing so: you'll have to create all the integration code including callouts, adding credentials to your Named Credentials, getting those from the external systems. Actually, if you have multiple systems subscribing to this event this requirement becomes exponentially complex with each new system that subscribes to it you choose to go this path.

Now imagine using Platform Events. You don't worry about credentials of other systems in Salesforce anymore. The only thing your other systems need to do is to subscribe to that event on Salesforce. You'll still have to code the trigger/Apex part, but not to worry about callouts from Salesforce anymore. An this is more scalable, as you don't need to change anything on the Salesforce side when adding a new system to the subscription. You will probably have to worry about handling this event for each new system that is part of the architecture, of course. But thinking about a scenario where you have independent teams owning each system/tool within an IT department, this approach makes things simple for the people managing Salesforce and the people subscribing to Salesforce's events.

tl;dr: Using a pub-sub approach with Platform Events is ideal for complex scenarios where CDC is not enough and you have multiple systems subscribing to the same event.

  • just curious is it really scalable considering subscription governer limits of platform events? Nov 4, 2023 at 18:34
  • You might have some limits regarding the amount of events you can subscribe or the amount of subscribers, but if I remember correctly those can be increased if you talk to Salesforce (if you are willing to pay extra, that is). Nov 4, 2023 at 18:38

In addition to the other comments, Platform Events are an ideal way to change the running user.

  • Using the metadata type PlatformEventSubscriberConfig you can define the running user to be (typically) a service user with elevated CRUD and sharing permissions

I've done this in a couple of use cases:

  • When a guest user kicks off processing that otherwise can't be CRUD permissioned or sharing permissioned to a Guest User
  • When I needed to operate on ContentWorkspace (libraries) that the running user might not be able to see due to Library permissions
  • Do be aware that there is a known issue with PlatformEventSubscriberConfig in unit tests that has not yet been addressed. I believe that using permission sets (and manually assigning them to the "Automated Process User") is the workaround for this. Just something to be aware of if you're trying to make use of Platform events within Salesforce (as opposed to, say, on Heroku or entirely off-platform).
    – Derek F
    Dec 29, 2023 at 21:22
  • Thanks @DerekF - I've noticed this is in the debug logs - fortunately, because I use the fflib pattern, the PE triggers immediately delegate the sobjects to the domain class and in my domain unit tests, I can use test.runAsUser to mimic non-test context behavior
    – cropredy
    Dec 29, 2023 at 21:47

Event-driven architecture tends to be a more efficient method of communicating between systems. This is because the subscribers don't have to continually check for updates (polling), publishers don't have to worry about which subscribers are listening, and adding or removing publishers and subscribers don't involve changes in code or even configuration.

As such, Platform Events tend to be more efficient in areas they are designed to be used in (e.g. notifying external systems). Generally speaking, anything you can do with a Platform Event you can do with something else instead. However, there is one notable exception.

Normally, in Salesforce, all the results of a transaction, except for callouts, can be rolled back in the face of a fatal error, such as an uncaught exception or a governor limit being exceeded. Callouts themselves are limited to before any database-altering methods are called, such as a DML operation. However, you can use a PE with a Deliver Immediately setting to write data somewhere, even if the transaction ultimately fails.

This is useful for writing debug logs, crash data, or pretty much anything else you can think of before the crash occurs. Of course, you have to be able to call the publish function, so you can't log data from, say, a limit exception, but it's great for retaining data regarding a controlled error condition.

Considering that callouts are blocked once the database has been altered, PE is the only way you can have any data survive a transaction. It's incredibly niche, but can be extremely useful. The rest of the time, PEs work for small workloads, despite their own governor limits.


In addition to the points in other answers, Platform Events can be used to perform what is effectively asynchronous processing outside the initiating transaction in a sequential (or narrowly controlled concurrent) manner by including one (or more) apex trigger based subscriber.

This is a great way of separating heavy processing from the original transaction or to allow callouts in reaction to DML operations, while ensuring this processing does not face race conditions.

You can read about these use cases (and why Platform Events work better within governor limits) in my apexhours article where you can also find a link to an example implementation. You will also find a further code example, focused more on callouts, here.


Are there any scenarios where platform events are the only option to choose from?

As far as I know there isn't any. Mainly because platform events are based on Streaming API which is existing already for a long time and have very similar capabilities -> Main difference is that Platform Events are more of a declarative tool (there are multiple ways of publishing/subscribing to PE), and Streaming API is only code.

So the solution is not unique, unique is how events (and not only Salesforce events -> but general principle work).

Or it is in most cases just an another tool to use?

And because of the above (existence of Streaming API) the answer is: Yes.

Personally, besides obvious technical implementations: publish event from one place (Salesforce Org) but multiple subscribers, I like to use PE for example to change context -> so for example it's needed for Chatter notifications (you cannot "notify" yourself). Another one is catching PE by multiple LWCs.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .