The One-Sentence Difference

Platform Events are custom events you define and publish. Change Data Capture (CDC) is automatic events Salesforce emits whenever records change on subscribed objects.

Both flow through Salesforce’s Event Bus. Both can be consumed externally (via the Streaming API) or internally (via triggers, flows, and Apex). Picking between them comes down to who controls the event shape and why.

Platform Events

Platform Events are first-class metadata. You define an event with fields — OrderPlaced__e with OrderId__c, Amount__c, CustomerId__c. You publish events by inserting them; you subscribe by writing Apex triggers, Flow subscribers, or external streaming consumers.

Strengths:

  • You control the shape. Only the data that matters travels.
  • Small payloads. Fast delivery.
  • Semantic clarity — the event name describes the business meaning (“Order Placed”) rather than a generic “Account Updated.”
  • Retained in the event log (usage-tiered) for replay.

Weaknesses:

  • You must explicitly publish them. Publishers need to know what to emit.
  • Changes to the event schema are irreversible without a new version.
  • Delivery has quotas per org per 24 hours.

Change Data Capture

CDC is a Salesforce-managed event stream. When a record on a CDC-enabled object changes, Salesforce emits an event containing the changed fields and the operation type (CREATE, UPDATE, DELETE, UNDELETE).

Strengths:

  • No publisher code. Just enable CDC on the object.
  • Emits for every change — including API-driven, UI-driven, and other automation.
  • Schema-complete — every field that was changed is in the event.
  • Supports full record retrieval via header info.

Weaknesses:

  • Noisy. You get events for changes that don’t matter to your subscriber.
  • Payload is larger and schema-heavy.
  • Semantic ambiguity — “Opportunity was updated” is not “Opportunity was won.”
  • Daily event quotas apply per object.

When Platform Events Fit

Use when:

  • You want to publish business events with intent: “Payment Received,” “Lead Qualified,” “Ticket Resolved.”
  • The subscriber cares about a specific semantic, not raw data changes.
  • You’re integrating across systems with clean contracts.
  • You need low-latency, lightweight delivery.

Example: an e-commerce integration where each order completion publishes an OrderPlaced__e. External warehouse management subscribes. Refund flows publish RefundIssued__e. Finance subscribes. Each event is intentional and decoupled.

When CDC Fits

Use when:

  • You’re mirroring data to an external system (data lake, warehouse, search index) and need to catch all changes.
  • You want to react to any modification to an object regardless of source.
  • You don’t own the code that modifies the records — UI, third-party packages, admins.

Example: mirroring Account and Contact changes to a data warehouse. Enable CDC on both objects, stream to the warehouse via the Pub/Sub API, and you capture every change without instrumenting every code path.

Hybrid Pattern: CDC + Platform Events

Mature orgs often use both.

  • CDC for comprehensive audit/mirror streams to data platforms.
  • Platform Events for business-critical, semantic events consumed by specific services.

The two streams serve different audiences. CDC is for data consumers. Platform Events are for workflow consumers.

Delivery Semantics

Both use the Event Bus. Both are at-least-once delivery — subscribers must tolerate duplicate deliveries. Implement idempotency in your subscribers.

Event order within a single publisher is preserved. Cross-publisher ordering is not guaranteed. If ordering matters across publishers, you need to impose it yourself (sequence numbers, timestamps).

Event retention is tiered — typically 72 hours at standard tier, longer on extended retention SKUs. If a subscriber goes down for a weekend, it can replay on recovery up to the retention window. Past that, events are lost.

Publishing Platform Events

List<OrderPlaced__e> events = new List<OrderPlaced__e>{
    new OrderPlaced__e(OrderId__c = 'ord-123', Amount__c = 250, CustomerId__c = 'cust-99')
};
EventBus.publish(events);

Published events are queued in the current transaction. They deliver when the transaction commits — so if the transaction rolls back, the events don’t publish. This is the desired behavior for most use cases.

For “publish immediately” semantics (used rarely), mark the event as Publish Immediately in the event definition. It publishes at the moment of EventBus.publish() call, not at transaction commit.

Subscribing Internally

Subscribe via a trigger on the event:

trigger OrderPlacedTrigger on OrderPlaced__e (after insert) {
    for (OrderPlaced__e evt : Trigger.new) {
        // react
    }
}

Or subscribe via a Platform Event-triggered Flow — declarative, convenient for simple reactions.

Subscribing Externally

The Pub/Sub API is the modern, recommended option (gRPC-based). It replaces the older CometD Streaming API for most use cases. Pub/Sub supports higher throughput, better reconnection, and integrates natively with major cloud platforms.

Use Salesforce’s client libraries or a gRPC client. Maintain a replay ID so your subscriber can resume from the last consumed event after a restart.

Limits to Budget For

  • Platform Event Publishes: tiered by license — a mid-tier allocation is typically in the low millions per 24 hours.
  • CDC Events: same structure, tiered by license. Enable CDC selectively — don’t enable it on every object.
  • Concurrent CometD Clients: legacy; Pub/Sub has different but generous limits.
  • Event Message Size: ~1 MB max payload. CDC events with many changed fields can approach this.

Exceeding publish limits silently drops events. Monitor usage in Setup → Platform Events → Usage.

Common Mistakes

CDC for everything. Teams enable CDC on 30 objects and get overwhelmed by volume. Be selective.

Platform Events for data replication. If you find yourself publishing an event every time any field changes, you’re reinventing CDC poorly. Use CDC.

Subscribers without idempotency. At-least-once delivery is real. A subscriber that processes a duplicate event as a new event will create duplicate records.

Ignoring replay. Subscribers that don’t persist replay state start from scratch on every restart, missing events or replaying too much.

Decision Rule

  • Publishing intentional business semantics to known consumers? → Platform Events.
  • Mirroring raw data to a downstream system? → CDC.
  • Both? Use both.

Frequently Asked Questions

Can a Platform Event trigger a Flow?

Yes. Use a Platform Event-Triggered Flow. This is the easiest subscriber for internal use cases.

Does CDC affect record-triggered flow execution?

No. CDC events are emitted after the transaction commits. They don’t change the order of execution for synchronous automation.

Can I filter CDC events at the source?

Partially — you choose which objects to enable CDC on, and you can filter subscriptions on the consumer side. Fine-grained per-field filtering at the publisher is limited.

What about High-Volume Platform Events?

Standard-Volume and High-Volume tiers differ in retention and delivery guarantees. High-Volume is standard for most modern use; Standard-Volume is legacy.

Share