Enabling CDC is a one-click toggle per object. The harder work is on the subscriber side: building the Pub/Sub or CometD client, handling replay, processing events idempotently. Plan the subscriber architecture before enabling CDC because once events start flowing, downstream systems need to consume them or events expire on the bus.
- Identify which objects need change tracking
List the Salesforce objects whose changes external systems need to consume. Account, Contact, Opportunity are common. Custom objects supporting integrations also fit. Each org has a limit on the number of objects, so choose deliberately.
- Enable CDC in Setup
Setup > Change Data Capture > Select Entities. Pick the objects, save. Events start flowing immediately. The Change Event Allocations section shows the daily allocation and current consumption.
- Build the subscriber via Pub/Sub API
The modern subscriber pattern uses the gRPC-based Pub/Sub API. Build a client in your language of choice with the published proto files. Subscribe to the appropriate ChangeEvent topic, process events, and persist the last successful replayId.
- Handle replay correctly
On reconnection, resume from the last persisted replayId. Without replay state, the subscriber starts from now and misses events that arrived during the offline window. Build replay handling as a first-class feature, not an afterthought.
- Process events idempotently
Subscribers may receive the same event multiple times due to retries. Build idempotent processing: check whether the downstream system has already applied the event, skip duplicates. The replayId is a natural deduplication key.
- Build the in-org Apex subscriber if needed
For in-org reactions to CDC events, write an Apex trigger on the ChangeEvent object: trigger AccountCDCHandler on AccountChangeEvent (after insert). The trigger fires asynchronously when events arrive.
- Add monitoring for gap overflow and disconnections
Build alerts on GAP_OVERFLOW events (subscriber fell behind) and on subscriber disconnection duration. Both indicate replication problems that need investigation before downstream data drifts.
- Build reconciliation for critical replication
For replication that must stay accurate, run a periodic reconciliation: compare Salesforce record counts and timestamps against the downstream system. Catch divergences early before they accumulate.
Which objects publish change events. Limited by entitlement; select based on actual integration needs.
Pub/Sub API (gRPC, modern) or CometD (long-polling, legacy). Pub/Sub is the strategic direction for new integrations.
Persist the last successful replayId. On reconnection, resume from that point. Without replay, offline events are lost permanently.
- CDC events retain for 72 hours. Subscribers offline longer than that lose events permanently. Critical replication needs reconciliation jobs to detect and recover.
- GAP_OVERFLOW events indicate the subscriber fell behind. The platform skips events to catch up. Build alerting on this event type and triage the cause before data diverges.
- Daily event allocations cap CDC throughput. Excessive change volume on selected objects can exceed the cap, dropping events silently. Monitor Platform Event Usage daily.
- Events publish after transaction commit. Rolled-back transactions produce no events. Subscribers should not assume a CDC event always indicates a permanent state change visible immediately to other queries.
- Only changed fields appear in CDC payloads. Subscribers reconstruct full record state by combining payload with cache or by querying the REST API for the complete record.