What are Salesforce Platform Events?<\/h2>\n\n\n\n
Salesforce Platform Events are custom messages that you define like a custom object, with an API name ending in __e. Each event has fields that carry data, such as Enrolment_Id__c and Amount__c. Events go onto the event bus, a stream that keeps them for a short time so subscribers can read them in order.<\/p>\n\n\n\n
Think of a radio station. The station broadcasts a message once, and every radio tuned to that channel hears it. The station does not call each listener, and new radios can tune in at any time. In this picture, the event bus is the radio channel, and subscribers are the radios.<\/p>\n\n\n\n
Why Salesforce Platform Events Matter<\/h2>\n\n\n\n
Direct calls between systems make them depend on each other. Here is why Salesforce Platform Events matter at Bright Path Tutors.<\/p>\n\n\n\n
- \n
- First, the payment partner sends a “payment received” event, and Salesforce updates the enrolment.<\/li>\n\n
- Also, when a course is cancelled, several systems must react, such as email, accounting and the website.<\/li>\n\n
- Next, the publisher stays simple, because it only sends one event.<\/li>\n\n
- New subscribers can join later without changing the publisher.<\/li>\n\n
- Finally, events can carry data out of Salesforce in near real time.<\/li>\n<\/ul>\n\n\n\n
So Salesforce Platform Events keep systems loosely coupled and easy to extend.<\/p>\n\n\n\n
How Salesforce Platform Events Work<\/h2>\n\n\n\n
Salesforce Platform Events follow a publish and subscribe flow. First, an admin or developer defines the event and its fields in Setup. Next, a publisher creates an event instance and calls EventBus.publish, or an outside system publishes through an API. Then the event goes onto the event bus, with a ReplayId that marks its position. After that, each subscriber receives the event, for example an Apex trigger on the event object. Finally, the subscriber processes it in its own transaction, separate from the publisher’s.<\/p>\n\n\n\n
![\"Salesforce](\"https:\/\/swapnilzambare.com\/blog\/wp-content\/uploads\/2026\/11\/salesforce-platform-events-apex-diagram-1-1024x640.png\")
How events move from publisher to subscribers.<\/figcaption><\/figure>\n\n\n\n Defining an Event<\/h3>\n\n\n\n
Create events in Setup > Platform Events. Add fields like you would on a custom object. Events have no record pages and are not stored like normal records.<\/p>\n\n\n\n
Publish Behaviour<\/h3>\n\n\n\n
Each event has a publish behaviour. Publish After Commit sends the event only if the transaction succeeds. Publish Immediately sends it at once, even if the transaction later fails, which suits logging.<\/p>\n\n\n\n
Publishing from Apex<\/h3>\n\n\n\n
Call EventBus.publish with one event or a list. It returns Database.SaveResult values that tell you whether publishing was accepted.<\/p>\n\n\n\n
Subscribing with Apex Triggers<\/h3>\n\n\n\n
Event triggers support only after insert. They run in their own process, by default as the Automated Process user, and can receive up to 2,000 events per batch.<\/p>\n\n\n\n
Other Subscribers<\/h3>\n\n\n\n
Flows can start from a platform event. Lightning components can subscribe with the empApi module. Outside systems use the Pub\/Sub API.<\/p>\n\n\n\n
Retries and Replay<\/h3>\n\n\n\n
Throw EventBus.RetryableException to ask Salesforce to send the batch again, up to 9 times. Each event has a ReplayId, so subscribers can resume from a position after a break.<\/p>\n\n\n\n
Publish After Commit vs Publish Immediately<\/h2>\n\n\n\n
The table below compares the two publish behaviours.<\/p>\n\n\n\n
Feature<\/th> Publish After Commit<\/th> Publish Immediately<\/th><\/tr><\/thead> Sent when<\/td> Transaction commits<\/td> At once<\/td><\/tr> If the transaction fails<\/td> Event is not sent<\/td> Event is still sent<\/td><\/tr> Typical use<\/td> Business events<\/td> Logs and monitoring<\/td><\/tr> Matches saved data<\/td> Yes<\/td> Not always<\/td><\/tr> Default for new events<\/td> Yes<\/td> No<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n When to use which is simple. Use Publish After Commit for business events that depend on saved data. Use Publish Immediately for logs that must survive a rollback.<\/p>\n\n\n\n
![\"Salesforce](\"https:\/\/swapnilzambare.com\/blog\/wp-content\/uploads\/2026\/11\/salesforce-platform-events-apex-diagram-2-1024x640.png\")
Publish After Commit vs Publish Immediately.<\/figcaption><\/figure>\n\n\n\n Payment_Received__e Fields<\/h2>\n\n\n\n
The table below lists the fields of our event.<\/p>\n\n\n\n
Field<\/th> Type<\/th> Example<\/th><\/tr><\/thead> Enrolment_Id__c<\/td> Text(18)<\/td> a025g00000XyZ12AAB<\/td><\/tr> Amount__c<\/td> Number(16, 2)<\/td> 5000<\/td><\/tr> Payment_Ref__c<\/td> Text(50)<\/td> PAY-2026-0911<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n A Real Salesforce Platform Events Example<\/h2>\n\n\n\n
Let’s use Salesforce Platform Events at Bright Path Tutors. The payment partner publishes Payment_Received__e, and Salesforce marks the enrolment as paid.<\/p>\n\n\n\n
Step 1: Publish from Apex<\/h3>\n\n\n\n
Payment_Received__e evt = new Payment_Received__e(\n Enrolment_Id__c = 'a025g00000XyZ12AAB',\n Amount__c = 5000,\n Payment_Ref__c = 'PAY-2026-0911');\n\nDatabase.SaveResult sr = EventBus.publish(evt);\nSystem.debug(sr.isSuccess() ? 'Event published' : 'Publish failed: ' + sr.getErrors());<\/code><\/pre>\n\n\n\nIn production, the partner publishes through an API. Here we publish Salesforce Platform Events from anonymous Apex to test. The SaveResult shows whether the event bus accepted it.<\/p>\n\n\n\n
Step 2: Subscribe with a Trigger<\/h3>\n\n\n\n
trigger PaymentReceivedTrigger on Payment_Received__e (after insert) {\n\n Map<Id, Payment_Received__e> byEnrolment = new Map<Id, Payment_Received__e>();\n for (Payment_Received__e evt : Trigger.new) {\n byEnrolment.put(Id.valueOf(evt.Enrolment_Id__c), evt);\n }\n\n List<Enrolment__c> updates = new List<Enrolment__c>();\n for (Id enrolmentId : byEnrolment.keySet()) {\n updates.add(new Enrolment__c(Id = enrolmentId, Is_Paid__c = true));\n }\n Database.update(updates, false, AccessLevel.SYSTEM_MODE);\n}<\/code><\/pre>\n\n\n\nThe trigger collects the enrolment Ids from all events in the batch, then updates them in one DML statement. Because it runs as the Automated Process user, it uses system mode explicitly, and allOrNone false keeps one bad Id from failing the rest.<\/p>\n\n\n\n
Step 3: Check the Result<\/h3>\n\n\n\n
Here is what the debug logs show for the publisher and the subscriber.<\/p>\n\n\n\n
Publisher: USER_DEBUG|Event published\nSubscriber: CODE_UNIT_STARTED|PaymentReceivedTrigger on Payment_Received__e\n DML_BEGIN|Op:Update|Type:Enrolment__c|Rows:1<\/code><\/pre>\n\n\n\nThe publisher and subscriber run in separate transactions. So the trigger’s log has its own entry, and its success does not affect the publisher.<\/p>\n\n\n\n
Testing Salesforce Platform Events<\/h2>\n\n\n\n
Publish events between Test.startTest and Test.stopTest. The events are delivered at stopTest, so your asserts see the trigger’s results. You can also call Test.getEventBus().deliver() to deliver them earlier.<\/p>\n\n\n\n
Common Mistakes with Salesforce Platform Events<\/h2>\n\n\n\n
- \n
- Expecting event triggers to support before insert or update events.<\/li>\n\n
- Using Publish Immediately for business events that need saved data.<\/li>\n\n
- Forgetting that event triggers run as the Automated Process user.<\/li>\n\n
- Retrying forever with RetryableException instead of handling the error.<\/li>\n\n
- Writing non-bulk trigger code for batches of up to 2,000 events.<\/li>\n<\/ul>\n\n\n\n
Best Practices for Salesforce Platform Events<\/h2>\n\n\n\n
- \n
- Name events after business facts, such as Payment_Received__e.<\/li>\n\n
- Keep event payloads small and focused.<\/li>\n\n
- Write bulk-safe triggers that handle many events at once.<\/li>\n\n
- Check SaveResult after every publish.<\/li>\n\n
- Monitor event usage against your org’s allocations.<\/li>\n<\/ul>\n\n\n\n
Practice Task<\/h2>\n\n\n\n
Create a Course_Cancelled__e event with a Course_Id__c field. Publish it from the course trigger when Status changes to Cancelled, and subscribe with a flow that emails enrolled students. Hint: use Publish After Commit so emails go out only when the cancellation is saved.<\/p>\n\n\n\n
Most Asked Interview Questions on Salesforce Platform Events<\/h2>\n\n\n\n
Event-driven questions are common in integration interviews. Here are the 21 questions asked most about Salesforce Platform Events.<\/p>\n\n\n\n
Basic Questions on Salesforce Platform Events<\/h3>\n\n\n\n
Q1: What are platform events?<\/strong><\/p>\n\n\n\n
Custom messages, ending in __e, that publishers send and subscribers receive through the event bus.<\/p>\n\n\n\n
Q2: How do you publish an event in Apex?<\/strong><\/p>\n\n\n\n
Call EventBus.publish with an event instance or a list of events.<\/p>\n\n\n\n
Q3: What does EventBus.publish return?<\/strong><\/p>\n\n\n\n
Database.SaveResult values that show whether publishing was accepted.<\/p>\n\n\n\n
Q4: Who can subscribe to platform events?<\/strong><\/p>\n\n\n\n
Apex triggers, flows, Lightning components with empApi, and outside systems through the Pub\/Sub API.<\/p>\n\n\n\n
Q5: Which trigger event do platform event triggers support?<\/strong><\/p>\n\n\n\n
Only after insert.<\/p>\n\n\n\n
Q6: What is the event bus?<\/strong><\/p>\n\n\n\n
A stream that holds events in order so subscribers can receive them.<\/p>\n\n\n\n
Q7: What is a ReplayId?<\/strong><\/p>\n\n\n\n
A value that marks an event’s position on the bus, used to resume subscriptions.<\/p>\n\n\n\n
Code and Scenario Questions on Salesforce Platform Events<\/h3>\n\n\n\n
Q8: What is the difference between the two publish behaviours?<\/strong><\/p>\n\n\n\n
Publish After Commit sends only if the transaction succeeds. Publish Immediately sends at once.<\/p>\n\n\n\n
Q9: Which user runs a platform event trigger by default?<\/strong><\/p>\n\n\n\n
The Automated Process user.<\/p>\n\n\n\n
Q10: How many events can a trigger batch contain?<\/strong><\/p>\n\n\n\n
Up to 2,000.<\/p>\n\n\n\n
Q11: How do you retry an event trigger?<\/strong><\/p>\n\n\n\n
Throw EventBus.RetryableException. Salesforce retries up to 9 times.<\/p>\n\n\n\n
Q12: How do you test a platform event trigger?<\/strong><\/p>\n\n\n\n
Publish between startTest and stopTest, or call Test.getEventBus().deliver(), then assert.<\/p>\n\n\n\n
Q13: Can you roll back a published event?<\/strong><\/p>\n\n\n\n
Not with Publish Immediately. With Publish After Commit, a failed transaction never sends it.<\/p>\n\n\n\n
Q14: How do you process part of a batch and resume later?<\/strong><\/p>\n\n\n\n
Use setResumeCheckpoint with the last processed ReplayId.<\/p>\n\n\n\n
Advanced Questions on Salesforce Platform Events<\/h3>\n\n\n\n
Q15: Why use platform events instead of direct callouts?<\/strong><\/p>\n\n\n\n
They decouple systems, so publishers and subscribers can change independently.<\/p>\n\n\n\n
Q16: Why should an event trigger use explicit access modes?<\/strong><\/p>\n\n\n\n
It runs as the Automated Process user, which may lack object and field permissions.<\/p>\n\n\n\n
Q17: How long are events kept on the bus?<\/strong><\/p>\n\n\n\n
For a limited time, typically up to 72 hours, so subscribers can replay recent events.<\/p>\n\n\n\n
Q18: Can you change the running user of an event trigger?<\/strong><\/p>\n\n\n\n
Yes, with a PlatformEventSubscriberConfig setting.<\/p>\n\n\n\n
Q19: What are event allocations?<\/strong><\/p>\n\n\n\n
Limits on how many events an org can publish and deliver in a period.<\/p>\n\n\n\n
Q20: How do platform events differ from Change Data Capture?<\/strong><\/p>\n\n\n\n
Platform events carry custom messages you design. Change Data Capture sends events for record changes automatically.<\/p>\n\n\n\n
Q21: How do you avoid duplicate processing?<\/strong><\/p>\n\n\n\n
Make subscribers idempotent, for example by checking a unique Payment_Ref__c before updating.<\/p>\n\n\n\n
Official Resources<\/h2>\n\n\n\n