Platform Events vs Change Data Capture in Salesforce

Introduction

Salesforce's modern event bus gives you two very different ways to tell the outside world that something happened: Platform Events and Change Data Capture (CDC). Both are durable for replay within the retention window, both can be consumed through Pub/Sub API, and both can drive Apex triggers, Flow, and external integrations. But they are not interchangeable.

The cleanest way to choose is to ask one question first: are you publishing a business fact, or are you exposing a record mutation?

Another important framing from Salesforce documentation: Pub/Sub API is not a third event type. It is a transport and subscription interface that works with both Platform Events and CDC.

What each event type means

That difference in publisher intent is the whole architecture story. Platform Events express meaning at the business layer. CDC expresses meaning at the data-change layer.

Side-by-side comparison

A lot of confusion comes from treating CDC as if it were a business API. It is not. CDC tells subscribers that Salesforce data changed. If subscribers should react to a meaningful business step, define that step explicitly as a Platform Event.

Code examples

These examples are intentionally simple and map to the documented event model. The Platform Event examples use a custom event contract. The CDC example shows how change subscribers work with ChangeEventHeader.

Platform Event publisher in Apex

Use Platform Events when you want to publish a business fact that is independent from the internal shape of the source record.

public with sharing class OrderEventPublisher {
    public static void publishSubmitted(Order orderRecord) {
        Order_Submitted__e eventRecord = new Order_Submitted__e(
            Order_Id__c = String.valueOf(orderRecord.Id),
            Account_Id__c = String.valueOf(orderRecord.AccountId),
            Order_Number__c = orderRecord.OrderNumber,
            Status__c = 'Submitted',
            Submitted_At__c = System.now()
        );

        Database.SaveResult publishResult = EventBus.publish(eventRecord);

        if (!publishResult.isSuccess()) {
            for (Database.Error err : publishResult.getErrors()) {
                System.debug(LoggingLevel.ERROR,
                    err.getStatusCode() + ': ' + err.getMessage());
            }
        }
    }
}

The event schema is yours. That is why Platform Events are a better contract when subscribers should not care whether the source process touched one object, three objects, or a dozen fields behind the scenes.

Platform Event subscriber with an Apex trigger

Platform Event triggers are always after insert because the event has already been published onto the bus.

trigger OrderSubmittedSubscriber on Order_Submitted__e (after insert) {
    List<Task> followUps = new List<Task>();

    for (Order_Submitted__e eventRecord : Trigger.New) {
        followUps.add(new Task(
            Subject = 'Process submitted order ' + eventRecord.Order_Number__c,
            Status = 'Not Started',
            Priority = 'Normal',
            Description =
                'Order Id: ' + eventRecord.Order_Id__c +
                '\nAccount Id: ' + eventRecord.Account_Id__c +
                '\nSubmitted at: ' + String.valueOf(eventRecord.Submitted_At__c)
        ));
    }

    if (!followUps.isEmpty()) {
        insert followUps;
    }
}

CDC subscriber with an Apex trigger

CDC is different. You do not publish the change event yourself. You enable the object for CDC in Setup, and Salesforce inserts change events when the tracked record changes.

trigger AccountChangeSubscriber on AccountChangeEvent (after insert) {
    for (AccountChangeEvent changeEvent : Trigger.New) {
        EventBus.ChangeEventHeader header = changeEvent.ChangeEventHeader;

        if (header.changeType == 'UPDATE') {
            System.debug(LoggingLevel.INFO,
                'Record ids: ' + header.recordIds +
                ', transaction key: ' + header.transactionKey +
                ', changed fields payload: ' + header.changedFields +
                ', current Name value: ' + changeEvent.Name);
        }
    }
}

Notice the contract difference. In CDC, the subscriber reasons about changeType, recordIds, and the source-object fields carried on the event. That is great for data synchronization and change processing, but it is a different abstraction than a business-domain event.

External topic naming with Pub/Sub API

Salesforce's Pub/Sub quick starts document the topic naming rules clearly, which is helpful when comparing the two models from an integration-client perspective.

Custom Platform Event: /event/Order_Submitted__e
Standard-object CDC:  /data/AccountChangeEvent
Custom-object CDC:    /data/Shipment__ChangeEvent
All tracked CDC:      /data/ChangeEvents

Delivery, replay, and payload details

Salesforce documents the event bus as a time-ordered event log. Platform Events and CDC events are stored on that bus for 72 hours. A subscriber can persist the last processed replay position and ask for missed events again, as long as that replay point is still inside the retention window.

• Store replay positions durably: never keep them only in memory if you care about reconnect recovery.
• Separate event meaning from transport: Platform Events vs CDC is an architecture decision; Pub/Sub API vs Streaming API is a transport decision.
• Decode CDC deltas correctly: Salesforce documents changedFields, diffFields, and nulledFields on CDC headers.
• Know the Pub/Sub payload shape: Pub/Sub API CDC messages include unchanged fields with empty values, while changedFields tells you what actually changed.

That last point is easy to miss and matters a lot. If you inspect a Pub/Sub CDC message and assume every field shown in the payload changed, your subscriber logic will be wrong. The documented delta indicators in ChangeEventHeader are the reliable guide.

Decision framework

In mature orgs, the answer is often both. CDC can feed operational sync and analytics, while Platform Events express curated business milestones such as Customer_Tier_Changed__e or Invoice_Approved__e.

Common mistakes

• Using CDC as a business-domain API: that couples subscribers to your object model and CRUD behavior instead of a stable process contract.
• Using Platform Events as a raw replication stream: that usually recreates CDC badly and forces you to hand-maintain an object-shaped contract.
• Ignoring replay storage: both event types are replayable only if your subscriber persists replay IDs and reconnect logic correctly.
• Forgetting CDC enablement: no object selection in Setup means no CDC events, even if the subscriber code is ready.
• Assuming one event per trigger execution: Salesforce event triggers still need bulk-safe logic, and the documented Apex trigger batch size for Platform Events and CDC is larger than standard object-trigger batches.
• Misreading CDC payloads in Pub/Sub API: use changedFields, nulledFields, and diffFields instead of assuming every field shown changed.

Recommendation

Use Platform Events when you want Salesforce or an external publisher to announce a business event intentionally, with a clean contract that can survive internal data-model changes. Use CDC when you want subscribers to react to Salesforce record mutations themselves.

If you are still unsure, choose based on what the subscriber is supposed to understand. If the subscriber should understand business intent, publish a Platform Event. If the subscriber should understand which Salesforce record changed and how, use CDC. Then consume either one through Pub/Sub API when you want a single external interface and replay-aware subscriber design.

References

• Get Started with Pub/Sub API
• Pub/Sub API and the Expanded Event Bus
• Event Types
• Event Message Durability
• Step 3: Set Up Events
• Step 4: Write Code That Subscribes to an Event Channel
• Step 5: Subscribe to Change Events
• Event Deserialization Considerations
• Create and Configure the Custom Platform Event
• Apex Governor Limits