Salesforce CDC vs Platform Events: Which One Should You Use?

Salesforce Change Data Capture (CDC) and Platform Events both publish messages through Salesforce's event infrastructure, but they solve different integration problems.

A practical way to start is:

Need to know that Salesforce records changed?
    → Change Data Capture

Need to publish a purpose-built business event?
    → Platform Events

That distinction is more useful than choosing based only on connector configuration.

Change Data Capture

CDC publishes change notifications for supported Salesforce records when they are:

created
updated
deleted
undeleted

The event is generated from record activity in Salesforce.

A typical use case is keeping another system synchronized with Salesforce data.

Salesforce Account changes
        │
        ▼
     CDC event
        │
        ▼
     MuleSoft
        │
        ▼
 downstream customer system

You usually do not create a custom event-producing action in the business process just to tell consumers that a record changed.

Platform Events

Platform Events are explicit event contracts that represent something meaningful that occurred in a business process or system workflow.

Examples might be:

OrderSubmitted
CustomerOnboardingCompleted
InvoiceApproved
ProvisioningRequested

The producer intentionally publishes the event, and the event schema is designed around that business or integration contract.

Salesforce business process
          │
          ▼
     Platform Event
          │
          ▼
       MuleSoft
          │
          ├── downstream API
          ├── Kafka
          └── another application

The Core Difference

The simplest distinction is:

CDC
"this Salesforce record changed"

Platform Event
"this business/system event occurred"

Those statements can occasionally describe similar real-world situations, but the integration semantics are different.

Choose CDC for Data Synchronization

CDC is usually a strong fit when your requirement sounds like:

Keep another system aware of changes to Salesforce records.

Examples:

synchronize Account updates into a data platform;
propagate Contact changes to another application;
update downstream caches or operational stores;
replace frequent polling for supported objects;
react to create/update/delete activity on Salesforce records.

CDC naturally aligns with entity-change integration.

Choose Platform Events for Business Contracts

Platform Events are usually a better fit when your requirement sounds like:

Publish a deliberate event that other systems should react to.

Examples:

a quote was approved;
an onboarding workflow completed;
a fulfillment request was created;
a business milestone occurred;
Salesforce needs to issue a command-like integration signal to another system.

The event contract can contain fields chosen for the consumers rather than simply representing a record change.

Avoid Using CDC as a Business-Event Substitute

Suppose an integration needs to react when an opportunity reaches a particular business milestone.

You could consume every Opportunity CDC update and make MuleSoft inspect the changed fields and infer whether the milestone occurred.

That can work, but it may create unnecessary coupling:

Opportunity changed
      │
      ▼
consumer understands Salesforce fields
      │
      ▼
consumer infers business event

If the business concept is important and intentionally published, a Platform Event can make the contract clearer:

Business milestone occurs
      │
      ▼
MilestoneCompleted event

Consumers no longer have to infer business meaning from raw record changes.

Avoid Publishing Platform Events for Every Data Change

The reverse problem also occurs.

If the only requirement is to propagate Account field changes, creating a custom Platform Event for every update can duplicate functionality CDC already provides.

That adds event-maintenance logic and another schema without necessarily adding business meaning.

Use a purpose-built event when there is a purpose-built contract.

Payload Semantics Differ

CDC events describe Salesforce record changes and include change-event metadata.

Platform Event fields are explicitly designed by the event publisher.

That difference affects consumer design.

With CDC, MuleSoft often asks:

Which record changed?
Which fields changed?
What is the current or changed state?

With Platform Events, MuleSoft often asks:

What event occurred?
What contract did the producer promise?
What action should the consumer take?

Replay and Recovery Apply to Both

Both CDC and Platform Events participate in Salesforce's event-retention and replay model.

Salesforce currently documents event retention for 72 hours, and Replay IDs are opaque positions used for event-stream recovery rather than business identifiers.

For MuleSoft consumers, keep these concepts separate:

Replay ID
    = where consumption resumes

Business/Event identity
    = what logical work this message represents

Recovery state
    = what failed and still needs remediation

A stored Replay ID is not a replacement for idempotency or a durable Error Hospital.

What Happens After the Retention Window?

If a consumer is offline long enough that required events are no longer retained, replay alone cannot reconstruct every missed change.

For CDC, reconciliation can often query the authoritative Salesforce data and restore downstream state.

For Platform Events, the answer depends more heavily on the business semantics. If the event represented a historical fact that cannot be reconstructed from current record state, the architecture may need its own durable record of that work outside the event bus.

CDC Can Be State-Oriented

CDC frequently supports integrations where the final objective is:

make downstream system match Salesforce state

If an old CDC event becomes stale, re-fetching the current record may be safer than replaying an obsolete snapshot.

For example:

version 10 failed
version 11 succeeded

later replay version 10

Blindly applying the older state could overwrite something newer.

Version/change awareness and reconciliation matter.

Platform Events Can Be Fact-Oriented

A Platform Event may represent a historical business fact:

PaymentAuthorized
ShipmentRequested
ApprovalCompleted

If such an event fails downstream, replacing it with current Salesforce record state may not preserve the meaning of the original event.

That is why Platform Event recovery often needs stronger attention to stable event identity, idempotency, and durable recovery context.

What About Record-Triggered Automation?

A Salesforce record-triggered Flow or Apex logic can publish a Platform Event when a record transition represents a meaningful business event.

That lets you convert:

record-level state transition

into:

explicit event contract

The trade-off is additional producer logic and governance. Use it when that explicit business contract provides real value.

A Quick Decision Table

Requirement	Better starting point
Synchronize Salesforce record changes	CDC
Replace polling for supported record changes	CDC
Detect create/update/delete/undelete activity	CDC
Publish a deliberate business event	Platform Events
Design a consumer-oriented event schema	Platform Events
Notify several systems of a business milestone	Platform Events
Reconstruct current downstream state	Often CDC + reconciliation
Preserve a historical business fact	Often Platform Event + durable recovery design

You Can Use Both

Large integration landscapes often need both patterns.