What is Salesforce Change Data Capture: A Practical Guide

Keeping external systems aligned with your Salesforce data is one of the most persistent challenges for modern enterprises. Traditional approaches use scheduled API calls or database extracts to detect changes. Those methods introduce delays, consume a lot of API capacity and often lead to stale information in downstream systems. Clients ask why their data warehouse or ERP doesn’t reflect the latest opportunity updates, and the answer is usually that someone is still running a batch job overnight.

As a Salesforce cloud consultant working across multiple industries, I’ve seen first-hand how batch integrations can hold businesses back. Modern architectures demand responsive, event-driven synchronization, systems need to know the moment a lead is converted, a case is escalated or an order is updated. That’s where changing data capture Salesforce capabilities make the difference. By publishing change events as soon as they happen, change data capture eliminates polling and empowers you to build near real-time integrations, analytics pipelines and automation.

This practical guide explains how Salesforce change data capture works, how to enable it, and how to design robust, scalable pipelines. You’ll learn about the core components of the CDC architecture, how it compares with Platform Events and PushTopic streaming, and what limits to watch for. We’ll walk through setup steps with screenshots, discuss real-world use cases, and highlight common pitfalls to avoid. By the end you’ll understand when and how to use CDC effectively as part of your integration strategy. Before enabling CDC in production, teams should validate event flows and subscriber behavior using a structured Salesforce sandbox strategy.

Understanding Salesforce Change Data Capture

{
  "replayId": "123456789",
  "commitTimestamp": "2024-05-20T10:15:30.123Z",
  "transactionKey": "005xx0000012345AAA",
  "schemaVersion": "1.0"
}

{
  "entityName": "Account",
  "changeType": "UPDATE",
  "recordIds": ["001xx000003DGbAAO"],
  "changedFields": {
    "Name": "Acme Corporation",
    "Industry": "Technology"
  }
}

At its heart, Salesforce change data capture is a publish-and-subscribe service built into the platform. Whenever a record is created, updated, deleted or undeleted, Salesforce generates a change event. That event is placed on the platform’s event bus and made available to subscribers via the Streaming API or Pub/Sub API. Instead of asking, “What changed?” every few minutes, your consumers simply listen to the event stream and react immediately.

Change events are JSON payloads containing both metadata and data. The header includes a replay ID, commit timestamp, transaction key and schema version. The body lists the record IDs and changed fields. CDC supports both standard and custom objects, and Salesforce automatically generates event channels (for example, AccountChangeEvent, OpportunityChangeEvent). Subscribers can listen to a specific object’s channel or to a merged ChangeEvents channel that aggregates events from multiple objects. While Change Data Capture handles ongoing updates, organizations still need strong Salesforce data migration when performing initial data loads or system consolidation projects.

Core Components of Salesforce Change Data Capture

Several building blocks make this real-time service possible:

Change events: An event is emitted whenever a record is inserted, updated, deleted or undeleted. Each event contains only the fields that changed plus important header attributes like the transaction ID. This payload structure keeps messages lightweight.Event channels: A dedicated channel exists for each enabled object. You can also use the aggregated ChangeEvents channel to consume multiple objects together. Each channel resides on the Salesforce event bus and retains events for up to 72 hours.

Replay IDs: Every event has a unique replay ID. Durable subscribers record the last replay ID they processed. If a connection drops, they can reconnect using that ID to replay missed events within the retention window. High-volume change data capture events share the same 72-hour retention limit as high-volume platform events.

Merged events and schema versioning: When multiple changes occur in a single transaction, Salesforce can emit a merged change event. The schema version field lets subscribers detect if the underlying object schema has changed. That’s crucial when adding new fields or renaming columns.

Streaming API and Pub/Sub API: Consumers can subscribe via the classic CometD-based Streaming API or the gRPC-based Pub/Sub API. The Pub/Sub API offers higher throughput and simplified client libraries, making it a great fit for modern microservices.

A change to an employee record produces a change event on the event bus. Multiple subscribers, such as an ERP system, data warehouse or marketing platform, consume the event concurrently and update their own records accordingly.

Benefits and Use Cases of Change Data Capture in Salesforce

Moving away from batch processes toward event-driven integration unlocks a variety of benefits. Because change data capture in Salesforce publishes events in near real time, you reduce latency, cut API consumption and improve data consistency. Below are some of the most common use cases I implement for clients.

Real-Time Analytics and Dashboards

Sales and service leaders need fresh data. Streaming CDC events into your analytics platform keeps dashboards continuously updated. Instead of waiting for nightly refreshes, pipeline updates appear seconds after they happen. This is especially valuable for pipeline management, support queue monitoring and compliance dashboards. When integrated correctly, CDC enables near real-time reporting across tools like Snowflake, Databricks, or BigQuery.

Incremental Data Warehouse Loads

Traditional ETL loads large tables on a schedule. With CDC you can process only the rows that changed. Each event carries the record ID and changed fields, so your ETL process can apply inserts and updates incrementally. This approach reduces compute costs and ensures that the data warehouse always reflects the latest state. It’s a common pattern for teams using salesforce change data capture events to keep centralized storage in sync without moving full tables.

Operational System Synchronization

Many organizations run critical operations across multiple applications. Using change data to capture Salesforce integration patterns, changes in one system can propagate immediately to others. For example, updating an account in Salesforce can trigger an automatic update in an ERP or billing platform. Likewise, closing a deal can immediately update provisioning systems. These patterns support microservices architectures, keep master data consistent and reduce manual work.

Event-Driven Workflows and Automation

CDC is the backbone of event-driven automation. When a record crosses a threshold or enters a certain status, downstream processes can react automatically. For instance, escalating a case can trigger a workflow in a customer support platform, while updating a contact’s tier can push a message to a loyalty system. This near real-time reaction improves customer experience and reduces human intervention.

How the event bus fans change events out to multiple subscribers, including external applications like SAP, Workday and Oracle. By subscribing once to the event stream, each downstream service stays up to date without interfering with others.

Example: Real-Time Integration with ERP and Marketing systems

Imagine a business that runs Salesforce for sales and an ERP system for order fulfillment. When an opportunity is closed-won, a CDC event fires. The integration layer consumes that event and creates a corresponding order in the ERP. Simultaneously, a marketing automation platform receives the same event to trigger a welcome campaign. The data warehouse also applies the update to maintain consistent reporting. This end-to-end flow happens within seconds, no need for nightly jobs or manual exports.

Common Challenges and Limits

While CDC is powerful, there are important limitations to understand:

Event volume management: High-traffic orgs can generate a large number of events. If you enable too many objects or track high-frequency updates (like logging every field change), downstream systems may fall behind. Filtering to only the objects and fields you truly need keeps event volumes manageable.

Event retention window: High-volume CDC events are stored on the event bus for 72 hours. If your subscriber is offline longer than that, you risk losing messages. Durable subscribers should record the last replay ID and reconnect as soon as possible.

Object and field support: Not every standard object or field type emits CDC events. For instance, some compound or formula fields may not trigger events. Always consult the product documentation to confirm support for your objects, and test thoroughly.

Partial payloads and lookups: Change events include only the modified fields. If your downstream system requires the full record, you’ll need to query Salesforce for the current state or maintain your own cache. This is a common pattern when building analytics pipelines.

Consumption limits: The Streaming API imposes limits on concurrent clients and events per second. High-volume events can handle a larger throughput than standard events, but you must still design for scalability. Techniques like batching, queueing and back-pressure handling are essential when processing large streams.

Enabling Salesforce Change Data Capture

Activating CDC for your objects is a straightforward administrative task. You don’t need code to turn it on, but planning is crucial. Follow these steps to enable change data capture Salesforce successfully:

Step-by-Step Setup

Log in to Salesforce: Sign in to your org with a profile that has administrative permissions. The following screenshot shows the standard login page used to access the platform.

Navigate to Change Data Capture: In Setup, enter “Change Data Capture” in the Quick Find box. Select change data capture under Integrations. You will see a list of available entities.

Select objects: From the available entities list, choose the standard and custom objects you want to track. Keep your selection narrow at first; enable only the entities you plan to consume. In the screenshot below you can see how to enable CDC for a custom object.

Save and deploy: Click Save to enable event publishing for the selected objects. Salesforce starts producing change events instantly for future transactions. There’s no need to deploy code or restart processes.

Assign permission sets: Users who subscribe to change events need the “View All Data” permission or specific event access via permission sets. Ensure your integration accounts have the necessary rights.

Subscribing to Change Data Capture Events

Once CDC is enabled, you need to consume the events. You can test subscriptions using Workbench, a developer tool for the Salesforce APIs. After logging in through OAuth, navigate to Streaming Push Topics and select Change Event. Choose the channel you enabled (for example, AccountChangeEvent) and click Subscribe. Within seconds you’ll see a stream of JSON messages representing record changes.

The screenshot below shows a typical Workbench session for subscribing to a change event. The session ID and endpoint are obfuscated for security.

For production integrations, you’ll use the Streaming API or the newer Pub/Sub API. The Streaming API uses a CometD protocol over HTTP and supports long-lived connections. The Pub/Sub API is gRPC-based and offers higher throughput, bidirectional streaming and simpler client libraries. Both require an OAuth access token with the appropriate scope.

Handling Subscriptions in Code

When implementing a subscriber, consider these best practices:

• Maintain the last replay ID processed and use it to reconnect after failures. This prevents data loss within the 72-hour window.
• Implement idempotent processing. Because events can be replayed during reconnection or retries, your consumer should detect and ignore duplicate updates.
• Use asynchronous and buffered processing. Don’t block the subscription thread while performing downstream work. Write events to a queue and process them in separate worker threads to avoid backlogs.
• Monitor subscriber health. Track latency, throughput and error rates. Trigger alerts if the consumer falls behind or if events cannot be processed.

Comparing Change Data Capture, Platform Events and PushTopic Events

You have several publish-subscribe options on the Salesforce platform. While CDC isn’t the only event mechanism, it differs from Platform Events and PushTopic events in important ways. The table below summarizes the key differences. Keep in mind that tables should list concise facts rather than long explanations.

Feature	Change Data Capture (CDC)	Platform Events	PushTopic Events
Event generation	Automatic on record changes	User-defined business events	Based on SOQL query result
Schema management	Generated by Salesforce	Defined manually as custom object	Derived from selected fields
Retention window	72 hours for high-volume	24 hours (standard) or 72 hours (high-volume)	24 hours
Payload contents	Changed fields only	Fields defined on event object	Entire queried record
Use case	Data synchronization, replication, analytics	Business process notifications	Legacy real-time dashboards
Setup complexity	Minimal (enable object)	Requires custom event object	Must author SOQL and query filtering
Replay support	Yes, via replay ID	Yes, via replay ID	Limited support
Suitable for high volume	Yes	Yes (with high-volume events)	Limited

Platform Events are ideal for domain-driven business events, things like “OrderShipped_e” or “WarrantyExpired_e”. They require you to define the event schema and publish events via code. CDC, on the other hand, automatically publishes changes to Salesforce records. PushTopic events were the original streaming mechanism in Salesforce; they broadcast results of a SOQL query and are less flexible than CDC or Platform Events. In modern architectures I recommend CDC for data synchronization and Platform Events for domain-specific messages.

Best Practices for Implementing CDC

Successful CDC implementations follow a few consistent patterns. Based on years of integration work as a Salesforce integration consultant, here are my recommendations:

Limit Scope and Expand Gradually: Don’t enable every object out of habit. Start with the minimum set of entities your integration needs. Observe event volumes and adjust before adding more.

Design for Throughput and Resilience: Build subscribers that can handle spikes in activity. Use buffering or batching when writing to downstream databases. Avoid synchronous calls to external systems inside your subscription loop.

Handle Schema Changes Gracefully: Your subscriber should inspect the schema version field and adjust mappings dynamically. If a new field appears, log it and plan how to handle it. Avoid hard-coded assumptions.

Implement Durable Subscriptions: Always store the last replay ID and reconnect using it. If your integration runs in a serverless environment that may spin down, persist the ID externally so you can resume reliably.

Plan for Failure and Retries: Build logic to catch transient errors, back off and retry. Use dead-letter queues when an event cannot be processed after several attempts. This prevents faulty records from blocking the entire stream.

Monitor everything: Instrument your pipeline with metrics on event lag, processing throughput, error rates and subscriber uptime. Set thresholds and alerts so you know when to scale up resources or investigate.

Common Mistakes to Avoid

Many teams adopt CDC enthusiastically and then run into familiar obstacles. Avoid these traps:

Enabling too many fields: Tracking every field change can produce a torrent of events. Focus on the fields that truly matter to downstream systems.

Ignoring event ordering: Change events arrive in order but can be processed out of order if your subscriber uses multiple threads without proper coordination. Ensure that updates to the same record are processed serially or implement version checks.

Skipping replay planning: If you don’t implement a replay strategy, any network outage or maintenance window can cause lost events. Always record the last replay ID and be prepared to catch up.

Assuming full payloads: Remember that CDC events include only changed fields. If you need the full record, plan to query Salesforce or maintain a local cache.

Underestimating downstream impact: Even with high-volume events, downstream systems can become bottlenecks. When using CDC to update a data warehouse or ERP, make sure those systems can ingest events at the rate they’re produced.

Security and Governance Considerations

Publishing change events doesn’t bypass your security model. CDC adheres to Salesforce’s sharing rules and field-level security. However, subscribers can still access sensitive information, so plan for the following:

Permission control: Only grant CDC subscription access to trusted integration users. Use permission sets or OAuth scopes to restrict who can subscribe.

Data masking: If change events include personally identifiable information (PII), mask or remove those fields before forwarding them. Apply transformations in your integration layer when necessary.

Encryption and transport security: The Streaming and Pub/Sub APIs use HTTPS for transport. Ensure your integration clients validate certificates and use secure cipher suites.

Audit and monitoring: Enable Event Monitoring and review logs regularly to detect unauthorized subscriptions or unusually high event volumes. Establish operational ownership so someone is accountable for CDC hygiene.

Retention policies: Understand the 72-hour retention limit and plan for data recovery. If your compliance requirements demand longer retention, persist relevant event data in your own storage.

Summary

Adopting Salesforce change data capture transforms the way systems stay aligned. By publishing events automatically when records change, CDC shifts your integration strategy from expensive polling to responsive, event-driven synchronization. It allows analytics teams to build live dashboards, enables micro services to react instantly and ensures data consistency across your ecosystem.

Implement CDC thoughtfully: enable it for the objects you actually need, handle replay IDs carefully, design subscribers for scale and always monitor your pipelines. Understand the change data capture limits Salesforce imposes, 72 hours of retention and throughput caps, and build resiliency into your architecture. When combined with well-designed subscribers and robust governance, CDC is a powerful tool for any enterprise adopting real-time integration patterns.

As you plan your next integration project, consider where change data capture fits alongside Platform Events and other streaming mechanisms. For record-level data replication, CDC is usually the right choice. For business-level notifications, Platform Events remain essential. With careful design, both can coexist and power a truly responsive architecture that delivers fresh data to every system the moment it changes.