Salesforce Platform Events

A radio station broadcasts one signal, and thousands of listeners tune in at will. The station does not know who listens, and the listeners do not call the station. Platform Events bring the same idea to Salesforce. One part of a system publishes a message, and any number of subscribers receive it. The publisher and the subscribers stay independent, which makes large systems flexible.

Event-Driven Design in Plain Words

Traditional integrations connect two systems directly. System A calls System B, and if System B changes, System A breaks. Event-driven design places a message channel in the middle.

Traditional                    Event-driven
-----------                    ------------
 A ------> B                   A --> [ Event ] --> B
 A ------> C                                  |--> C
 A ------> D                                  |--> D
(A knows every system)         (A knows only the event)

Adding a new subscriber needs no change to the publisher.

What a Platform Event Is

A platform event is a custom object definition whose API name ends with __e. Fields describe the message content. Salesforce stores no permanent record for an event in the usual way. Events live on an event bus for a limited window, and subscribers read them from there.

Item	Detail
API suffix	__e, for example Order_Shipped__e
Fields	Custom fields that carry message data
Delivery	Asynchronous, in the order of publishing
Retention	High-volume events stay on the bus for 72 hours for replay

Define an Event: Step by Step

1. Open Setup and search for Platform Events.
2. Click New Platform Event.
3. Enter the label Order Shipped, which creates the API name Order_Shipped__e.
4. Choose when to publish: Publish Immediately or Publish After Commit.
5. Save and add custom fields such as Order_Number__c and Tracking_Code__c.

Publish After Commit sends the event only when the surrounding transaction succeeds. Publish Immediately sends the event even when the transaction rolls back later.

Publish an Event From Apex

Order_Shipped__e evt = new Order_Shipped__e(
    Order_Number__c = 'ORD-5501',
    Tracking_Code__c = 'PK1001'
);

Database.SaveResult sr = EventBus.publish(evt);
if (!sr.isSuccess()) {
    System.debug('Publish failed');
}

Publish an Event From a Flow

A flow publishes an event with the Create Records element. The admin chooses the event object and maps its fields, the same way as a regular record. A record-triggered flow can publish an event when an order reaches Shipped status.

Subscribe to an Event

Apex Trigger Subscriber

trigger OrderShippedTrigger on Order_Shipped__e (after insert) {
    List<Task> tasks = new List<Task>();
    for (Order_Shipped__e e : Trigger.new) {
        tasks.add(new Task(Subject = 'Notify customer: ' + e.Order_Number__c));
    }
    insert tasks;
}

Flow Subscriber

A platform-event-triggered flow starts whenever a matching event arrives. Admins build the reaction without code.

Lightning Web Component and External Subscribers

Components use the empApi module to listen for events and refresh the screen in real time. External systems subscribe through the Pub/Sub API and receive the same messages.

Example Scenario: Order Shipping

Warehouse system marks order shipped
              |
              v
   Salesforce publishes Order_Shipped__e
              |
     +--------+---------+------------------+
     |                  |                  |
     v                  v                  v
Flow sends email   Apex creates task   Billing system
to customer        for account owner   starts invoice

Three teams react to one message, and none of them depends on another.

Change Data Capture

Change Data Capture is a related feature. Salesforce publishes an event automatically whenever a record is created, updated, deleted, or undeleted on an enabled object. External systems stay synchronised with Salesforce data without polling.

Replay and Reliability

Each event carries a replay Id. A subscriber that disconnects reconnects later and asks for events after the last replay Id it processed. The 72-hour window lets the subscriber catch up on missed messages.

Best Practices

• Keep event payloads small and include record Ids rather than full data.
• Use Publish After Commit for business events that depend on saved data.
• Make subscribers safe to run twice, since delivery can repeat.
• Monitor allocation limits for event publishing and delivery.
• Name events after business facts, such as Order Shipped.