01. Introduction

In most Salesforce projects, data synchronization between Salesforce and other systems is an important requirement. Applications often need updated information as soon as a record changes.

For example, consider a customer updating their email address in Salesforce. The requirement may be to synchronize that change with SAP, a mobile application, a data warehouse, or another Salesforce organization.

One common approach is polling, where an external system repeatedly calls Salesforce at regular intervals and asks:

Although polling can work, it may generate unnecessary API calls, consume resources, and introduce delays between a record update and the moment another system discovers it.

This is where Salesforce Change Data Capture (CDC) comes into the picture. CDC allows Salesforce to publish events when records change, enabling subscribed applications to react without continuously querying Salesforce for updates.

02. What Is Change Data Capture?

Change Data Capture is a Salesforce event-driven mechanism that publishes change events when records in selected objects are created, updated, deleted, or undeleted.

When CDC is enabled for an object, Salesforce detects relevant record changes and publishes corresponding change events to the Salesforce event bus. Subscribers can listen to the relevant event channel and process those changes.

For example, when CDC is enabled for the Account object, its channel is:

/data/AccountChangeEvent

Subscribers that have the required access and subscribe through a supported interface can receive Account change events and take appropriate action.

03. Why Do We Need CDC?

Let’s consider an external application that needs to know whenever an Account’s email-related information changes.

Traditional polling approach

The external application might query Salesforce every two minutes to check for updated records.

• API requests may be made even when no records have changed.
• Frequent polling can consume API limits and processing resources.
• Updates may remain undiscovered until the next polling cycle.
• Multiple systems and large datasets can make polling more expensive.

CDC approach

With CDC, Salesforce publishes change events for the selected objects. Subscribed systems can process those events as they arrive rather than repeatedly querying for changes.

CDC is particularly useful for integrations that need timely updates across multiple systems. However, it does not eliminate all API usage or remove the need for reliable event-processing logic.

04. How Does CDC Work?

Let’s walk through the process of enabling CDC and delivering a Salesforce record change to subscribers.

Before: snehal@gmail.com
After:  snehal@cs.com

/data/AccountChangeEvent

CDC event flow at a glance

This event-driven architecture allows connected systems to react to changes without relying exclusively on scheduled polling.

05. Understanding AccountChangeEvent

One of the most important parts of CDC is understanding the event message. When an Account changes, the event contains a ChangeEventHeader, along with other event data.

A simplified example of a change event looks like this:

{
  "ChangeEventHeader": {
    "entityName": "Account",
    "recordIds": ["001XXXXXXXXXXXXXXX"],
    "changeType": "UPDATE",
    "changedFields": ["Email__c", "LastModifiedDate"],
    "transactionKey": "0003c5b2-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "sequenceNumber": 1,
    "commitTimestamp": 1760500000000,
    "commitUser": "005XXXXXXXXXXXXXXX"
  },
  "Email__c": "snehal@cs.com",
  "LastModifiedDate": "2026-10-15T09:30:00.000Z"
}

This is a simplified example to explain the header fields. Actual Salesforce change event payloads contain additional metadata, and the exact structure depends on the event and change type. The replayId is not part of ChangeEventHeader; it is delivered with the event metadata (for example, event.replayId in a CometD message).

Understanding the important fields

06. Where Can We Subscribe to CDC?

CDC is not limited to external systems. Salesforce and external applications can consume change events through supported subscription mechanisms.

1. Lightning Web Components (LWC)

A Lightning Web Component can use the lightning/empApi module to subscribe to supported streaming channels, including CDC channels in supported Salesforce environments.

For example, the channel name is:

const CHANNEL = '/data/AccountChangeEvent';

The component can listen for events and update the UI or display notifications when an Account changes. The component’s lifecycle, permissions, and subscription error handling should be considered.

2. Apex CDC Triggers

Salesforce supports Change Data Capture triggers that allow Apex logic to process change events inside Salesforce.

This is useful when a business process needs to respond to record changes with additional automation, such as invoking application logic or coordinating follow-up processing.

3. External Systems and Middleware

External applications can subscribe through supported Salesforce streaming interfaces and APIs. Middleware can then route events to SAP, data warehouses, mobile backends, or other applications.

07. Using Streaming Monitor as a CDC Subscriber

When learning CDC, it is helpful to inspect the events Salesforce actually publishes. A compatible streaming client or monitoring tool can help you observe the event stream and examine its payload.

For example, with a tool configured to subscribe to the Account CDC channel:

/data/AccountChangeEvent

You can follow this workflow:

1. Enable CDC for the Account object.
2. Configure the monitoring tool with the required Salesforce access.
3. Subscribe to the Account change event channel.
4. Update an Account record in Salesforce.
5. Inspect the received event and its metadata.

This is useful for understanding change types, record IDs, changed fields, and replay information. The exact setup depends on the monitoring tool and the Salesforce streaming API it supports.

08. Important CDC Considerations

CDC is powerful, but a reliable implementation requires more than enabling an object and subscribing to a channel.

1. CDC tracks selected objects

If CDC is enabled for Account, Salesforce publishes Account change events. This does not automatically provide a complete snapshot of every related Contact or Opportunity. Subscribe to the relevant objects and design additional queries or processing when needed.

2. Design subscribers for reliable processing

Subscribers should handle exceptions, transient failures, and downstream service outages. A failed integration should not silently lose an important business update.

3. Understand replay and retention

Replay IDs can help subscribers resume event consumption within the platform’s supported replay and retention window (change events are retained for about 3 days). They are not a permanent event archive, so long-term recovery may require a separate persistence strategy.

4. Avoid unnecessary processing

Not every change requires an expensive downstream action. Filter events according to business rules, process only relevant changes, and use asynchronous processing where appropriate.

5. Account for delivery and duplicate processing

Integration consumers should be designed to tolerate retries and duplicate processing where applicable. Use idempotent operations so processing the same logical change more than once does not create inconsistent results.

6. Check permissions and platform limits

Confirm the required permissions, supported API behavior, event delivery limits, and platform-specific constraints before deploying CDC in production.