We have been using Platform Events for a while now for certain core processing. When we created our Platform Events I don't recall there being an option to specify how publishing behaved. Publishing was (and is still, for our events) processed "decoupled" from the originating transaction. I see now that there's a "Publish Behavior" setting on the event:

New Platform Event screen

This is one of "Publish Immediately" or "Publish After Commit", with behaviours as explained in the above screenshot.

Part of the reason we adopted Platform Events for triggering certain in-app processes was to ensure that the records created and managed within it are recorded as created or modified by the Automated Process user, rather than the user who initiated the processing. This adds clarity as to how certain records were created/updated.

Now, we've found a nasty edge case scenario where our processing of the platform event happens too quickly, in solutions with lots of process builders etc., before the originating transaction has committed its data to the database. This means the processing initiated from the event trigger doesn't see this new data (despite itself being asynchronously invoked from the platform event trigger).

As such I am looking to change the publish behaviour for the events to "Publish After Commit".

The documentation for Apex Triggers for platform events states:

Unlike triggers on standard or custom objects, triggers on platform events don’t execute in the same Apex transaction as the one that published the event. The trigger runs asynchronously in its own process under the Automated Process entity.

I just wanted to verify that this holds true regardless of publish behaviour, before updating our package's platform events. Do you know if that's the case?

  • 1
    i had a long discussion with the PM on this 18 months ago where sometime in the future (which one would think would be now, but it is not), you could identify in the Platform Event definition your chosen running user. This would solve some other issues like Automated Process user unable to render VF email templates.
    – cropredy
    Oct 11, 2020 at 0:16

2 Answers 2


Without evidence to the contrary, I would presume the documentation is correct. I only have limited experience with Platform Event Triggers, but they do seem to obey this rule.

As a general rule of thumb, you want to use the Publish After Commit option if you want to work on the data within the trigger/code that called the Platform Event, because you can't query uncommitted data in a separate transaction.

You would want to use Publish Immediately only if you want to be able to persist data outside the current transaction (usually because the transaction itself is doomed to failure/rollback, but you still want a log of the transaction to persist).

  • 1
    To confirm, changing the publish behaviour did not disrupt the way the events were handled, but instead just changed the timing and whether or not the event was even processed (after commit requires that the originating session actually makes some changes to the DB and the session must be successful).
    – Phil W
    Apr 6, 2021 at 19:34

According to a trailhead on platform events, you do have the option to change who the running user of the platform event trigger is.

"You can override the running user of a platform event trigger so that the trigger runs under that user instead of Automated Process. Configure the trigger by using PlatformEventSubscriberConfig in Metadata API or Tooling API. For more information, see Configure the User and Batch Size for Your Platform Event Trigger in the Platform Events Developer Guide."

  • I am aware of that recent change which was made available after our original issue. Thanks.
    – Phil W
    Apr 6, 2021 at 19:32
  • 2
    BTW, I really don't understand why they didn't make this part of the trigger's metadata instead of a separate metadata object...
    – Phil W
    Apr 6, 2021 at 20:37

You must log in to answer this question.

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