Platform Events Developer Guide

Platform Events Developer Guide
Delivering Custom Notifications with Platform Events
Defining Your Custom Platform Event
Publishing Platform Events
Subscribing to Platform Events
Testing Your Platform Event in Apex
Encrypting Platform Event Messages at Rest in the Event Bus
Monitor Platform Event Publishing and Delivery Usage
Considerations
Defining and Publishing Platform Events
Processes and Flows
Apex and API
Decoupled Publishing and Subscription
What’s the Difference Between the Salesforce Events?
Examples
Reference
PDF

Considerations for Publishing and Subscribing to Platform Events with Apex and APIs

Before you use Apex or Salesforce APIs to publish and subscribe to platform events, familiarize yourself with these considerations.
Support Only for after insert Triggers
Only after insert triggers are supported for platform events because event notifications can’t be updated. They’re only inserted (published).
Infinite Trigger Loop and Limits
Be careful when publishing events from triggers because you could get into an infinite trigger loop and exceed limits. For example, if you publish an event from a trigger that’s associated with the same event object, the trigger is fired in an infinite loop.
Publishing Events in Apex with Text Fields Set to Empty Strings
If you publish an event in Apex with a Text field set to an empty string, the field value in the delivered event message is null instead of empty string. The Text field value of empty string is preserved when publishing through other methods, including APIs, flows, and processes.
Platform Event Triggers: OwnerId Fields of New Records
In platform event triggers, if you create a Salesforce record that contains an ownerId field, the system populates the field with Automated Process by default. To set this field to another value, you can configure the trigger to run as another user. That way, the OwnerId field references the selected user. For more information, see Configure the User and Batch Size for Your Platform Event Trigger with PlatformEventSubscriberConfig. Alternatively, if you don’t change the running user, you can set the ownerId field explicitly to the appropriate user when you create the record. This example explicitly populates the ownerId field for an opportunity with an ID obtained from another record.
1Opportunity newOpp = new Opportunity(
2    OwnerId = customerOrder.createdById,
3    AccountId = acc.Id, 
4    StageName = 'Qualification', 
5    Name = 'A ' + customerOrder.Product_Name__c + ' opportunity for ' + acc.name, 
6    CloseDate = Date.today().addDays(7));
For cases and leads, you can alternatively use assignment rules for setting the owner. For more information, see AssignmentRuleHeader for SOAP API or Setting DML Options for Apex.
Platform Event Triggers: Changing the Opportunity OwnerId Field
If a platform event trigger updates the opportunity OwnerId field when opportunity splits are enabled, the trigger runs as the default Automated Process system user. A set of opportunity splits is created that totals 0%. The 0% split is invalid and must be 100% when an opportunity owner is changed. The 0% split causes validation errors when users attempt to update some opportunity fields, such as the Amount and Owner fields. To avoid these issues, configure the platform event trigger so that it runs as a different user. For more information, see Configure the User and Batch Size for Your Platform Event Trigger with PlatformEventSubscriberConfig
No Email Support from a Platform Event Trigger
With the default Automated Process running user, sending an email message from a platform event trigger using the Messaging.SingleEmailMessage class isn’t supported. The email can’t be sent because the sender is the Automated Process entity, which has no email address. To send an email, change the running user of the trigger. For more information, see Configure the User and Batch Size for Your Platform Event Trigger with PlatformEventSubscriberConfig.
Replaying Past Events
You can replay platform events that were sent in the past. You can replay platform events through Pub/Sub API or Streaming API (CometD) but not Apex and other subscribers. For more information, see these resources.
Salesforce Maintenance Activities and Sandbox Refresh
On rare occasions, some Salesforce maintenance activities, such as an org migration to a new data center or an instance refresh, reset the stream of retained high-volume platform events. Also, a sandbox refresh can cause a move to another Salesforce instance, resulting in a stream reset. Because of the stream reset, the events are no longer available for replay. Also, the Replay ID of events published before the maintenance or sandbox refresh activity has no relation to the Replay ID of events after the activity. For more information, see How to Prepare for an Org Migration, Instance Refresh Maintenance, and Refresh Your Sandbox in Salesforce Help.
Site switches don’t affect the stream of retained events for subscribers, including Pub/Sub API, Streaming API, empApi Lightning components, Apex triggers, event relays, and flows. However, Apex triggers that are used as parallel subscriptions are affected if the trigger lags behind and hasn’t finished processing all events when the site switch occurs. In this case, the Apex trigger can’t continue processing unprocessed events from before the site switch. The parallel subscriptions resume from events newly published after the site switch. See Site Switching Overview and FAQ.
Using MuleSoft’s Salesforce Connector after a Hyperforce Migration or Sandbox Refresh
When a Salesforce instance is migrated to Hyperforce, the migration can result in an invalid Replay ID error in the Mule app. Also, performing a sandbox refresh can cause a move to another Salesforce instance, resulting in an invalid Replay ID error in the Mule app. The error can be returned if the Mule app tries to access a Replay ID from the object store that’s no longer valid on the new Hyperforce instance. See the knowledge article about steps to take to avoid the error.
Millisecond Time Precision in DateTime Fields
For event messages delivered to CometD clients in JSON format, the DateTime fields include the number of milliseconds. The date format, which is in the ISO 8601 standard, is YYYY-MM-DDTHH:mm:ss.sssZ. In API version 42.0 and earlier, DateTime fields don’t include the millisecond part of the time, and the DateTime format is YYYY-MM-DDTHH:mm:ssZ.
For event messages delivered to Apex triggers, DateTime fields don’t include millisecond precision, like DateTime fields of Salesforce objects.
Apex Trigger Subscriptions Disabled in Inactive Salesforce Orgs
If an org becomes inactive, all Apex trigger subscriptions are stopped and disabled. Triggers no longer process incoming event messages and can't process missed event messages. After the org is reactivated, new Apex trigger subscriptions are started when a platform event message is published.