Platform Event
A Platform Event is a Salesforce event object used to publish and subscribe to messages on the platform's event bus.
Definition
A Platform Event is a Salesforce event object used to publish and subscribe to messages on the platform's event bus. Publishers (Apex, Flow, Process Builder, or external systems via the API) create event records; subscribers (Apex Triggers, Flows, Lightning components, or external systems via CometD/Pub/Sub API) receive them and react. Platform Events decouple producers from consumers, enable asynchronous and event-driven architecture inside Salesforce, and integrate with external messaging systems through CometD or the newer Pub/Sub API.
Platform Events look like custom objects in Setup but have the __e suffix and operate under different rules. Records are immutable: once published, you cannot update or delete them. Subscribers receive events nearly in real time through a high-throughput streaming channel. The platform retains events for 72 hours by default for high-volume events and up to 24 hours for standard events, after which they are removed from the bus. Platform Events are the standard pattern for integration with external messaging systems, for fan-out notifications inside an org, and for event-driven Apex that should not run synchronously during the originating save transaction.
How Platform Events power event-driven architecture in Salesforce
Publishers, subscribers, and the event bus
Platform Events follow the publish-subscribe pattern. Publishers create event records with the EventBus.publish Apex method, the Create Records Flow element, or external POST calls to the REST API. The event lands on the event bus, a high-throughput streaming channel managed by Salesforce. Subscribers register interest in the channel and receive each new event asynchronously. The bus decouples producers from consumers: publishers do not know who is listening, subscribers do not know who published. This is the architectural win that distinguishes Platform Events from synchronous triggers and Apex calls.
High Volume versus Standard Volume events
Each Platform Event is configured as High Volume (the default since 2018) or Standard Volume (legacy). High Volume events scale to millions per day and retain for 72 hours on the bus. Standard Volume events are limited to 250,000 per day and retain for 24 hours. High Volume is the right choice for nearly every new use case; Standard Volume exists for backward compatibility with older subscribers that rely on its specific delivery semantics.
Apex triggers as subscribers
The most common Platform Event subscriber is an Apex trigger. Declare a trigger on the __e event type with after insert context: trigger MyEventTrigger on My_Event__e (after insert). Apex processes events in batches of 2,000 (configurable) and runs the trigger logic asynchronously, outside the original transaction that published the event. This is the standard pattern for fan-out work: publish an event in a synchronous flow, let the trigger handle the heavy lifting on the bus without blocking the user.
Flow subscribers and the Event-Triggered Flow type
Platform Event-Triggered Flow is one of the Flow types Salesforce introduced specifically to consume Platform Events declaratively. Build the Flow as event-triggered, pick the event type, and the Flow runs whenever a new event arrives. This is the no-code path to event-driven automation, useful for routing inbound events to record updates, notifications, or downstream system calls without writing Apex.
External subscribers: CometD and Pub/Sub API
External systems subscribe via two channels. The older CometD streaming endpoint supports bidirectional pub-sub with long-polling. The newer Pub/Sub API (gRPC-based) is faster, more efficient, and the strategic direction for new integrations. Both deliver events nearly in real time and respect the retention window. External subscribers must replay missed events using the replayId mechanism if they disconnect; without replay, events on the bus while the subscriber was offline are lost on reconnect.
Transaction boundaries and publish behavior
Platform Events publish in two modes: in-transaction (publish-after-commit) and immediate (publish-immediately). In-transaction publishes hold the event until the originating transaction commits successfully; if the transaction rolls back, the event is not published. Immediate publishes send the event regardless of the transaction outcome. The default is publish-immediate, but most production code wants publish-after-commit semantics for consistency. The publishBehavior field on the event metadata controls this choice.
Common patterns: integration, decoupling, observability
Integration: publish events when records change, subscribe from external systems via Pub/Sub API for real-time replication. Decoupling: publish events to defer heavy work outside the user-facing transaction, subscribe with Apex triggers that handle the work async. Observability: publish events for important business actions (Order Placed, Lead Converted, Case Escalated) and consume them with logging or monitoring subscribers. Each pattern beats synchronous triggers because the bus absorbs spikes and the subscriber processes at its own pace.
How to create and use a Platform Event
Platform Events are powerful but introduce async timing into your architecture. Plan the publisher pattern (Apex versus Flow versus external API), pick the subscriber model (Apex trigger versus Event-Triggered Flow versus external Pub/Sub), and decide on transaction publish behavior up front. Build in a sandbox with realistic publish volumes before going live.
- Identify the event use case and design the payload
List the business action (Order Placed, Inventory Updated, Lead Captured) and the fields the subscribers need to act. Keep the payload focused; events that try to carry every conceivable field become unmaintainable. Reference record IDs and let subscribers fetch additional data if needed.
- Create the Platform Event in Setup
Setup > Platform Events > New Platform Event. Enter label, plural label, API name (gets __e suffix), choose High Volume (default and recommended), and pick publishBehavior (publish-after-commit recommended for most use cases).
- Add custom fields
Add the fields the event payload needs. Field types are similar to custom objects: Text, Number, Date, Checkbox, Email, Phone, URL, Long Text Area. No lookup or master-detail fields because events are not records in the traditional sense.
- Publish events from Apex, Flow, or external API
Apex: EventBus.publish(new List<My_Event__e>{ new My_Event__e(Field__c = ''value'') }). Flow: Create Records element with the __e object. External: POST to /services/data/vXX.X/sobjects/My_Event__e/ with the field payload.
- Subscribe with an Apex trigger
trigger MyEventHandler on My_Event__e (after insert) { for (My_Event__e e : Trigger.new) { ... process event ... } }. Apex processes events in batches asynchronously. The trigger runs outside the publisher transaction.
- Subscribe with a Platform Event-Triggered Flow
Setup > Flows > New Flow > Platform Event-Triggered Flow. Pick the event type. Build the flow that runs whenever a new event arrives. No-code path for declarative subscribers.
- Subscribe externally via Pub/Sub API
Build a Pub/Sub API client (gRPC) and call Subscribe with the event type and replayId preset. The client receives events as they arrive. Implement replay handling so disconnections do not lose events on reconnect.
- Monitor publish and consumption rates
Setup > Platform Event Usage shows daily counts against the org allotment. Build a dashboard for high-traffic events to catch volume spikes early. Failed Apex subscribers retry with exponential backoff; monitor the SubscriberSnapshot for retry storms.
High Volume for nearly every new use case. Standard exists for legacy compatibility with very specific delivery semantics.
publish-after-commit holds the event until the transaction commits. publish-immediate sends regardless of outcome. Most use cases want publish-after-commit.
Apex trigger for in-org async processing. Event-Triggered Flow for declarative subscribers. Pub/Sub API for external integration.
- Platform Events are immutable. Once published, you cannot update or delete the event record. To correct a mistake, publish a compensating event with corrected data.
- Apex subscriber triggers run asynchronously, outside the publisher transaction. Code that assumes the event is processed synchronously will see stale state when the trigger has not yet fired.
- Daily event allotments cap high-volume publishing. The Setup > Platform Event Usage page shows current consumption. Build monitoring for orgs that approach the limit because exceeded events are silently dropped.
- External Pub/Sub subscribers must handle replay correctly. Disconnections without replay lose events that arrived during the offline window. Implement persistent replayId storage and resume from the last successful position.
- Publish-immediate events fire even when the originating transaction rolls back. Use publish-after-commit for any event tied to durable state changes to avoid orphan events that reference non-existent records.
Trust & references
Cross-checked against the following references.
- Platform Events OverviewSalesforce Help
- Platform Events Developer GuideSalesforce Developer
Straight from the source - Salesforce's reference material on Platform Event.
- Define a Platform EventSalesforce Developer
- Publish Platform EventsSalesforce Developer
- Subscribe to Platform Events with ApexSalesforce Developer
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. Where would a developer typically work with Platform Event?
Q2. What skill set is typically needed to work with Platform Event?
Q3. What is a Governor Limit in the context of Platform Event?
Discussion
Loading discussion…