Salesforce Platform Events Testing
Salesforce Platform Events testing validates event-driven integrations from publish to outcome — confirming an event is published at the right moment in the transaction, delivered to every subscriber, processed once, and turned into the correct result in Salesforce or an external system. SyntraFlow is designed to wait for asynchronous processing to settle and then assert on what the events actually caused, including replay after a subscriber goes offline.
Event and streaming validation is available for demonstration and proof-of-concept validation.
Why event-driven integrations are hard to test
Platform events decouple the publisher from the subscriber. A Flow, Apex class or external system publishes an event such as Order_Submitted__e to the event bus, and any number of subscribers — Apex triggers, platform event-triggered Flows, Pub/Sub API clients, middleware — react independently. That decoupling is the point, but it removes the simple request and response a test normally asserts against.
The publisher gets a result saying the event was queued for publishing, not that anyone processed it. Subscribers run later, in their own transactions, as a different user. A test that checks the outcome immediately after publishing will fail intermittently, and a test that only checks publishing will pass while every subscriber is broken. Event testing needs to follow the event across that gap and assert once processing has genuinely completed.
This page covers Platform Events and the closely related Change Data Capture stream. For synchronous request-based integrations, see Salesforce REST API testing; for middleware subscribers, see MuleSoft testing.
Testing an event from publish to outcome
SyntraFlow can be configured to trace an event through each stage and assert where it can fail.
Trigger the publishing action
The business action that publishes the event is performed with controlled data — a record update that fires a Flow, an Apex method, or an external publish through the API.
Confirm publish behavior
The test checks whether the event definition is set to publish immediately or publish after commit, and verifies the event behaves correctly when the publishing transaction succeeds and when it rolls back.
Wait for subscribers to settle
Instead of a fixed sleep, the test polls for the expected outcome with a timeout, so slow delivery is tolerated and genuine non-delivery is reported.
Assert each subscriber's result
Every subscriber is checked separately — a trigger that creates a task, a Flow that updates a status, an external client that writes to the ERP — so one working subscriber cannot mask a broken one.
Verify exactly-once outcomes
Record counts confirm each event produced one result, even when triggers were retried or the external subscriber reconnected.
Exercise replay
A subscriber is stopped, events are published, and on reconnect it resumes from its stored replay ID, proving no events were skipped within the retention window.
Publish and subscribe behaviors to validate
Platform event behavior is defined by a handful of settings and platform rules. Each has a testable consequence.
| Behavior | What to validate |
|---|---|
| Publish immediately | The event is sent even if the publishing transaction later fails, so subscribers must tolerate events for records that were rolled back |
| Publish after commit | The event is sent only when the transaction commits, and no event appears when it rolls back |
| Apex trigger subscribers | Triggers run as the Automated Process user or a configured user, process events in batches, and respect governor limits at volume |
| Resume checkpoints | Large batches use setResumeCheckpoint so a failure part way through does not reprocess events already handled |
| RetryableException | A trigger that throws EventBus.RetryableException is retried a limited number of times before the subscription is suspended |
| Platform event-triggered Flows | The Flow starts for each event, runs with the expected context and handles missing field values |
| Publishing and delivery allocations | Hourly publishing and daily delivery allocations are sized for peak volume and monitored |
| Event ordering | Subscribers that depend on order handle events from separate publishes arriving in an unexpected sequence |
Pub/Sub API and external subscribers
External systems increasingly subscribe through the gRPC-based Pub/Sub API. Its behavior needs its own checks.
Replay presets
Subscriptions start from LATEST, EARLIEST or a CUSTOM replay ID. Tests confirm a restarted client uses its stored replay ID rather than silently starting from LATEST.
Flow control
Clients request a number of events at a time. Tests confirm a slow consumer does not lose events and keeps requesting as it processes.
Schema handling
Event payloads are Avro-encoded against a schema ID. Tests add a field to the event definition and confirm the client fetches the new schema instead of failing.
Authentication and access
The client's user needs read access to the event or channel. Tests confirm a user without access is refused and that token refresh works on long-lived streams.
Publishing from outside
External systems can publish through Pub/Sub API or REST. Tests assert on the publish result for each event and handle per-event errors.
Custom channels
Channels and filter expressions limit which events a subscriber receives. Tests confirm filtered subscribers receive only matching events.
Change Data Capture checks
Change Data Capture streams record changes as events. It shares the event bus with Platform Events but has its own structure to verify.
- Change events are enabled for every object the integration relies on, including after a sandbox refresh or deployment.
- The ChangeEventHeader carries the expected changeType — CREATE, UPDATE, DELETE or UNDELETE — for each tested action.
- changedFields lists the fields that were actually modified, so a subscriber that syncs only changed fields does not miss updates.
- Changes committed in one transaction share a transactionKey, and subscribers that group by it reassemble the transaction correctly.
- Gap events and overflow events, which signal that the subscriber must fetch current record state, are handled rather than ignored.
- Enriched fields configured on a channel arrive in the payload so subscribers do not need extra API calls.
- Field-level security does not unexpectedly hide values the subscriber needs — see field-level security testing.
Unit tests versus end-to-end event tests
Apex tests can publish events and deliver them to triggers synchronously using Test.stopTest or Test.getEventBus().deliver(). That is valuable for checking trigger logic, but it runs inside a test context with no real event bus, no external subscribers, no replay and no allocations. It cannot show that a middleware subscriber received the event, that a Flow ran as the right user in a real org, or that the ERP ended up with the right order.
SyntraFlow is designed to fill that gap by running event scenarios in a real sandbox and asserting on the business outcome, wherever it lands. When the subscriber writes into an ERP or HCM system, the same scenario continues into that system and reconciles, as described on the data reconciliation testing page. When subscribers fail, retries and replay are explored further under integration error and recovery testing.
Common event defects and how tests expose them
These defects are specific to event-driven designs and are rarely caught by synchronous testing.
| Defect | How a test exposes it |
|---|---|
| Subscriber silently suspended after repeated errors | Outcome never appears within the timeout, and subscription status shows suspended |
| Event published for a rolled-back record | A failing transaction still produces a downstream action |
| Duplicate processing after reconnect | Two target records exist for one published event |
| Client resumes from LATEST after restart | Events published during downtime never produce outcomes |
| Trigger fails at volume | A burst of events exceeds governor limits in a single trigger batch |
| Schema change breaks external client | Events stop being processed after a field is added to the definition |
Related pages
Salesforce Integration Testing
The parent hub for APIs, events, middleware and cross-system validation.
Integration Error and Recovery Testing
Retries, dead-letter handling and replay after outages.
MuleSoft Testing
Validate middleware subscribers by what they deliver.
Data Reconciliation Testing
Confirm event-driven changes arrived correctly downstream.
Salesforce REST API Testing
Synchronous request and callout integrations for comparison.
Field-Level Security Testing
Make sure event payloads carry the fields subscribers need.
Platform Events Testing testing FAQs
What is Salesforce Platform Events testing?
Salesforce Platform Events testing validates event-driven integrations end to end. It confirms events are published at the right point in the transaction, delivered to every subscriber, processed exactly once, and produce the correct outcome in Salesforce or an external system, including after a subscriber reconnects and replays missed events.
How do you test asynchronous events without flaky tests?
Replace fixed waits with polling for the expected outcome against a sensible timeout. The test passes as soon as the outcome appears and fails with a clear message if it never does. This tolerates normal delivery delay while still catching events that were never processed.
What is the difference between publish immediately and publish after commit?
Publish immediately sends the event as soon as it is published, even if the surrounding transaction later rolls back. Publish after commit sends it only if the transaction commits. Tests should exercise both a successful and a failing transaction to confirm the chosen setting matches what subscribers expect.
What is a replay ID and why test it?
Each event on the bus has a replay ID. Subscribers store the last one they processed so they can resume from that point after a disconnect. Testing replay proves a restarted subscriber picks up every event published while it was down, within the retention window, rather than skipping them.
Is Change Data Capture tested the same way as Platform Events?
The approach is similar because both use the event bus, replay IDs and asynchronous subscribers. Change Data Capture adds its own structure to verify, including the change type, changed fields, transaction keys and gap or overflow events that tell a subscriber to re-read current record state.
Can SyntraFlow validate external Pub/Sub API subscribers?
SyntraFlow is designed to validate external subscribers by outcome — publishing or triggering events in Salesforce and confirming the expected result in the system the subscriber writes to. Coverage for your specific event definitions, channels and subscribers is confirmed during a proof of concept.
Follow every event to its outcome
See how SyntraFlow is designed to validate publish behavior, subscriber results and replay across your event-driven integrations.