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.