Sales reps spend 60% of their workweek on non-selling tasks like data entry, meeting prep, and internal admin. Only 35% completely trust their CRM data. Both stats come from Salesforce’s own State of Sales reports (2026 and 2024 editions).

We talk to Salesforce Admins and RevOps teams who build CDC pipelines expecting complete data on the other end. They get Opportunity changes, Account updates, Contact modifications. They don’t get a single email, meeting, or call. The activity data that matters most never made it into Salesforce.

This guide covers what Change Data Capture in Salesforce actually does, where it breaks, and how to close the gap.

What is Change Data Capture in Salesforce?

Salesforce Change Data Capture is a streaming feature on the Salesforce event bus. It publishes Salesforce change events whenever a tracked record is created, updated, deleted, or undeleted. External systems subscribe to the stream and get notified in near-real-time.

It sits alongside Platform Events and Real-Time Event Monitoring on the same infrastructure. The key difference: CDC events publish automatically based on record changes. Salesforce handles the publishing without Apex or Flows.

CDC is a notification stream. It tells your downstream systems something changed, delivers the payload, and moves on. Storage, auditing, and syncing are your problems.

You need Enterprise Edition or higher. You can track up to 5 standard or custom objects for free. Beyond that, you need the CDC add-on license.

The activity-data blind spot (and how to fix it)

Before getting into CDC’s technical details, there’s something you should know. It’ll change how you think about your entire implementation.

CDC can only stream what’s inside Salesforce. Sounds obvious. The problem: the data sales leaders care about most (emails sent, meetings held, calls made) often never gets there.

Einstein Activity Capture limitations

Salesforce’s built-in solution is Einstein Activity Capture (EAC). It connects to Office 365 or Gmail and pulls activity data into Salesforce.

Except “into Salesforce” is misleading.

EAC stores most activity data on AWS as virtual records. They show up in the Activity Timeline, which makes it look like they’re in Salesforce. They’re not. Here’s what that means for CDC:

• Virtual records aren’t Salesforce objects. CDC can’t publish events on them.
• They’re not queryable via the Salesforce API.
• They don’t appear in standard reports.
• Default retention is 6 months. Paid licenses extend it to 24 months, with a max of 5 years via support request.
• Remove someone’s EAC license and the virtual records get deleted.

If you’ve built a CDC pipeline expecting all sales activity to flow through, you’ll get Opportunity and Account changes just fine. You’ll get zero emails, meetings, or calls. The most valuable data for forecasting and pipeline visibility is invisible to CDC.

Your CRM data completeness will never hit 95% if the bulk of activity lives on a third-party cloud with a 6-month expiry.

How Revenue Grid closes the gap

Revenue Grid (that’s us 👋) writes activity data directly into Salesforce as native objects: Tasks, Events, and EmailMessages. Everything lives in Salesforce as regular records.

Because the data is in Salesforce as regular records:

• CDC sees it and publishes change events on it.
• It shows up in standard Salesforce reports and dashboards.
• It’s queryable via the API and SOQL.
• It syncs to your warehouse through your existing CDC pipeline.
• Retention is unlimited; not tied to any license.
• Custom objects are supported.

Revenue Grid’s automatic activity capture handles this without reps doing anything. The Inbox Sidebar lets them view and update Salesforce from Outlook or Gmail, so the records that CDC needs get created without anyone leaving their email client.

We’re biased, obviously. The architectural distinction matters regardless of which tool you pick. EAC stores activity outside Salesforce. Revenue Grid stores it inside Salesforce. If your CDC pipeline needs data inside Salesforce (it does), the storage location is the whole game.

How does Salesforce CDC work under the hood?

With the activity-data context covered, here’s how CDC works for the record types it can see.

Publish/subscribe model

CDC uses a publish/subscribe pattern on the Salesforce event bus. When a record you’ve selected for CDC gets modified (by a user, an API call, or an Apex trigger), Salesforce publishes a change event. Subscribers receive it in near-real-time.

Events are retained for 72 hours. If your subscriber disconnects and reconnects within that window, it can replay missed events using the replayId. After 72 hours, they’re gone.

What’s inside a change event

Each event includes a ChangeEventHeader:

For CREATE events, you get all populated fields. For UPDATE, only the changed fields plus the record ID. For DELETE, just the record ID and header info.

Detail most guides skip: encrypted fields are stored separately but still delivered in the same event. Same 72-hour retention.

How to subscribe to a CDC event in 2026

Four options. One correct answer for new implementations.

The Pub/Sub API hit GA on June 30, 2022. It uses gRPC, typed Avro schemas, and bi-directional streaming. Way better throughput than CometD.

If a guide leads with CometD or Salesforce Streaming API examples, it’s outdated.

Salesforce CDC vs. Platform Events vs. Field History Tracking vs. Streaming API

The question of Salesforce CDC vs Platform Events comes up a lot. Add Salesforce Field History Tracking and the Salesforce Streaming API and it gets confusing fast. Here’s the comparison.

Short version: CDC for streaming to external systems. Platform Events for custom event schemas. When evaluating Field History Tracking vs CDC, Field History is for queryable audit data with old/new values; CDC is for real-time downstream sync.

Nobody mentions this: Field Audit Trail can cost roughly 10% of your annual Salesforce spend. That puts CDC’s $60K/year add-on in a different light.

How do I enable Change Data Capture? Step-by-step Salesforce CDC setup

This Salesforce CDC tutorial covers the full Salesforce CDC setup: prerequisites, entity selection, subscription, validation, and monitoring.

Prerequisites

• Enterprise, Performance, Unlimited, or Developer Edition.
• “Customize Application” permission (typically System Administrator).
• Decision on subscription method: Pub/Sub API (recommended), Apex triggers, or iPaaS connector.

Step 1: Select your entities

Go to Setup > Quick Find > “Change Data Capture.” Two columns: Available Entities and Selected Entities.

Pick up to 5 objects. Each one counts toward your allocation. Need a sixth? That’s the $5K/mo add-on conversation.

The UI only shows selections for the default standard channel. Custom channels configured via Metadata API won’t appear here.

If you’re using Revenue Grid: Your sales activity is already native Tasks, Events, and EmailMessages. Include Task and Event in your 5 CDC entities and you get complete activity data streaming to your warehouse. With EAC, adding Task and Event only captures manually logged activities, not the auto-captured ones (those are on AWS).

Image idea: Annotated screenshot of Salesforce Setup > Change Data Capture. Two columns with 5 objects selected. Callouts: “Max 5 on default channel” pointing to Selected Entities, “Standard + custom objects both count” pointing to the list. Clean annotation style. Alt text: Salesforce Setup page showing Change Data Capture entity selection with Available Entities and Selected Entities columns. Caption: Five entity selections on the default channel. After that, it’s add-on license time. Filename: salesforce-cdc-setup-entity-selection-screenshot.png

Step 2: Choose your channel

CDC publishes to channels with a naming convention:

• Default (all entities): /data/ChangeEvents
• Per-object: /data/<ObjectName>ChangeEvent (e.g., /data/AccountChangeEvent)
• Custom: Configured via Metadata API for filtering and routing

Per-object channels are usually the right call. The default channel gets noisy when you’re tracking multiple objects and only one subscriber cares about one of them.

Step 3: Subscribe with Pub/Sub API

import grpc

from salesforce_pubsub import PubSub

auth = {
    "url": "https://login.salesforce.com",
    "client_id": "YOUR_CONNECTED_APP_CLIENT_ID",
    "client_secret": "YOUR_CLIENT_SECRET",
    "username": "YOUR_USERNAME",
    "password": "YOUR_PASSWORD"
}

channel = grpc.secure_channel(
    "api.pubsub.salesforce.com:7443",
    grpc.ssl_channel_credentials()
)

pubsub = PubSub(channel, auth)

for event in pubsub.subscribe("/data/AccountChangeEvent"):
    header = event.payload.ChangeEventHeader

    print(f"Change type: {header.changeType}")
    print(f"Record IDs: {header.recordIds}")
    print(f"Changed fields: {header.changedFields}")

This Salesforce CDC tutorial covers the Pub/Sub API path. If you’re on an iPaaS (MuleSoft, Workato, Boomi), most have pre-built CDC connectors. Less control, faster setup.

Step 4: Validate with Workbench

Test before production. Open Workbench, log in, subscribe to your channel, change a tracked record, confirm the event shows up. Five minutes. Saves hours.

Step 5: Monitor event delivery

Salesforce won’t alert you when events get dropped. Build your own monitoring:

• Track replayId gaps. Jump in IDs that doesn’t match expected event count = dropped events.
• Log commitTimestamp latency. Gap between Salesforce commit and subscriber receipt.
• Daily allocation check. Query EventBusSubscriber to track how much of your 24-hour budget you’ve used.

Where Salesforce CDC breaks

Most vendor blogs skip Salesforce CDC limitations because they’re inconvenient. Here’s the full list.

Salesforce CDC pricing: the 5-entity cap

5 entities on the default channel. That’s it. Entity number six requires the add-on.

The Salesforce Add-On Pricing PDF lists CDC at $5,000/org/month. That’s $60K/year before you’ve written any subscriber code.

The add-on removes the entity limit and bumps your delivery allocation. Everything else below still applies.

CDC event delivery limit

CDC shares its delivery allocation with all Platform Events in your org. The 24-hour caps, per Salesforce CDC Allocations:

The catch: one event delivered to five subscribers counts as five deliveries. Snowflake connector + Kafka consumer + Apex trigger + monitoring tool + backup subscriber = every event burns five allocations.

50K/day with five subscribers = 10K effective events. Enterprise orgs exceed that during quarter-end data loads easily.

72-hour retention

Events persist for 72 hours. After that, they’re permanently deleted. Salesforce keeps zero backup.

Real scenario: subscriber goes down Friday evening. Nobody notices until Monday. That’s 60+ hours. Add a holiday Monday and you’ve permanently lost everything from Friday through Sunday. Recovery means building replay-ID checkpoints and a reconciliation job comparing downstream data against a full SOQL extract.

No historical backfill

CDC only captures changes after you enable it. There’s zero mechanism to generate events for existing records. New warehouse integration? Full Bulk API load first, then CDC on top. Coordinating that cutover without gaps or overlaps is the hardest part of the implementation.

Formula fields excluded

CDC doesn’t publish events for formula fields. Also excluded: SystemModStamp, IsDeleted, and other derived fields.

This matters because formula fields are what sales leaders build forecasting dashboards on: win probability, days-in-stage, weighted pipeline. Formula recalculates when a referenced field changes, but CDC only captures the referenced field, not the formula result.

The Idea Exchange has an open request. Still unfulfilled. The workaround: create a regular field, use a Flow to copy the formula value on every change, track that field via CDC. It works. Nobody likes maintaining it.

Silent failure on bulk loads

The scary one. From Salesforce’s own developer blog:

Batch Apex updates, ETL jobs, and data loads can potentially overload your allocations and lead to failed event deliveries.

Translation: nightly ETL exceeds your allocation, CDC silently drops the overflow. Your downstream system stops getting events and you find out when someone notices stale data.

Good use cases for CDC

CDC is great at specific things. Here’s what those are.

• Salesforce data replication to a warehouse. A Salesforce CDC Snowflake pipeline (or BigQuery, or Redshift) is CDC’s sweet spot. Near-real-time replication without polling. When paired with Revenue Grid’s Salesforce-native capture, the same pipeline also gets the complete email, meeting, and call history that EAC orgs miss.
• Downstream automation. Opportunity hits “Closed Won,” CDC notifies billing, ERP, provisioning. All event-driven, all decoupled. See our guide on Salesforce automation tools for more.
• Customer data platforms. CDC feeds Kafka, EventBridge, or Azure Event Hub. Multiple downstream consumers tap one stream. Hub-and-spoke.
• Fraud and risk detection. Financial services companies flag suspicious changes as they happen: unusual amounts, rapid status changes, bulk updates from unexpected sources.

Not the right tool for

• Audit history with old/new values. CDC gives you the new value. Not the old one. Use Field History Tracking.
• Real-time UI for lots of users. Client limits (1K-2K) and per-subscriber delivery math make it expensive.

Best practices for 2026

• Use Salesforce Pub/Sub API. CometD is legacy. Pub/Sub gives you gRPC, Avro schemas, better throughput. Every new Salesforce integration starts here.
• One subscriber, then fan out. One event to five subscribers = five allocations. Run one subscriber (Kafka Connect, EventBridge, iPaaS), route internally. Five Kafka consumers don’t burn Salesforce allocations.
• Replay ID checkpointing from day one. Store last processed replayId in a database, S3, or Redis. On reconnect, resume. Insurance against the 72-hour cliff.
• Isolate ETL from your budget. Schedule batch jobs during low-allocation windows. Use custom channels to separate high-volume objects from pipeline-critical entities.
• Monitor at 70%. Dashboard tracking delivery count against 25K/50K ceiling. Alert at 70%. At 90%, it’s too late.
• Custom channels for noise reduction. Group entities, apply field filters. Subscribers only get what they need.
• Make sure activity data is actually in Salesforce. Your warehouse analyzes what CDC sends it. If activity lives on AWS instead of Salesforce, no CDC config fixes that. Revenue Grid’s Salesforce-native architecture solves it at the source. Einstein Activity Capture doesn’t.
  

Who feels what

CDC is great at what it does: streaming record changes to external systems. The mistake is assuming it captures everything. Activity data only reaches CDC if it’s native Salesforce records. That’s the line between a complete pipeline and one with a hole in it.