Salesforce gives architects more than one way to move changes and business signals between systems. The hard part is deciding what the event should mean. A record update and a business event can happen at the same moment, but they carry different intent. If an Opportunity moves to Closed Won, one subscriber may need the changed Salesforce fields while another only needs a clear signal that a sale was completed.
That distinction is the center of the Platform Events vs Change Data Capture decision. Salesforce Platform Events let a producer publish a message with a schema you define. Salesforce Change Data Capture creates change events automatically when supported Salesforce records are created, updated, deleted, or undeleted. Both can support a Salesforce event-driven architecture, but they solve different integration problems and create different contracts for publishers and subscribers.
This guide compares the 2 models from the point of view that matters in production: intent, payload control, transaction meaning, replay, ordering, volume, subscriber design, and failure recovery. It also covers hybrid designs because many mature Salesforce estates need both event types rather than one universal event stream.
TL;DR
Choose Salesforce Platform Events when the event represents a business fact or command-like notification that you want to name and shape yourself, such as Payment Received or Order Released. Choose Salesforce Change Data Capture when another system needs to know that Salesforce record data changed and should react to or replicate that change. The Salesforce event-driven architecture decision guide treats platform events and CDC as preferred mechanisms for record and field change notifications consumed by other systems, while also warning that event-driven patterns are a poor fit when a process requires an immediate synchronous response. That boundary is useful before comparing product features.
For most Platform Events vs Change Data Capture decisions, start with 1 question: is the subscriber interested in the business meaning of what happened, or in the Salesforce data mutation itself? A business meaning usually points to Platform Events. A data mutation usually points to CDC. If both matter, use both and keep their responsibilities separate.
Key points:
· Platform Events use a publisher-controlled event schema and require an explicit publish action.
· CDC uses a Salesforce-generated change event schema tied to the source object and publishes automatically for enabled record changes.
· Both use the Salesforce event bus and can be consumed by external systems through the Salesforce Pub/Sub API.
· Both have a 72-hour event retention window for replay, so long outages still need a separate reconciliation plan.
· CDC gives subscribers transaction metadata such as transactionKey and sequenceNumber, which is useful for replication and multi-record transactions.
· High-volume custom Platform Events can use parallel Apex subscriptions, while change events can’t use that feature.
What Salesforce Event Models Actually Do
An event model defines more than transport. It defines the contract between the system that produces a message and the systems that consume it. In a Salesforce event-driven architecture, that contract answers 4 practical questions: what caused the message, who controls its schema, what the payload means, and how a subscriber recovers when delivery is interrupted.
The Salesforce platform groups several event mechanisms under its event features, but Platform Events and CDC are the 2 choices most often compared for new event integrations. Salesforce explains that custom platform events carry custom messages while Change Data Capture events are tied to Salesforce record and field changes. That makes the core design difference semantic rather than cosmetic. A custom event can say OrderReleased__e. A change event says that an Order__c record changed and includes metadata describing the change.
The right contract depends on whether the consumer needs source-system detail or a stable business signal. A record-level stream couples the consumer to Salesforce object structure, while a business event can expose a smaller contract chosen by the event owner.
The Salesforce event bus is the common transport layer for both models. That shared transport can make the 2 approaches look interchangeable from the outside, especially when the same external client can subscribe through the Salesforce Pub/Sub API. They aren’t interchangeable because the production and payload semantics are different.
How Salesforce Platform Events Work
Salesforce Platform Events are custom event definitions that behave like message contracts. You create an event definition, add the fields consumers need, choose publishing behavior, and then publish event instances from Salesforce automation, Apex, or an external application. The publisher decides when the event exists.
That explicit publication is the main reason Platform Events fit business events. A record can change several times during a process, yet only one of those moments may be meaningful outside Salesforce. For example, an order record might move through validation fields before it becomes ready for fulfillment. Publishing an Order_Released__e event at the approved point gives subscribers a clear contract instead of asking each subscriber to infer the meaning from several record changes.
The schema is also under your control. Salesforce documents the custom fields you add and the Platform Event field settings include the choice between Publish Immediately and Publish After Commit. Publish Immediately can send an event even if the surrounding database transaction later fails. Publish After Commit waits for a successful commit. That choice can change what a subscriber is allowed to assume about Salesforce data when it receives the event.
Publishing can happen from Flow, Apex, or external APIs. Salesforce’s publishing guide lists those supported publishing paths, which makes Platform Events useful when Salesforce is either the producer or one participant in a wider integration. An external system can publish a Platform Event into Salesforce, something CDC doesn’t provide because CDC is generated from Salesforce record changes.
Your team owns the event name, fields, publication rule, versioning, and failure handling. That work makes sense for an explicit business contract, but it is extra work when the goal is only to mirror Salesforce data.
How Salesforce Change Data Capture Works
Salesforce Change Data Capture is source-driven. You enable supported entities for CDC, and Salesforce emits change events when records on those entities are created, updated, deleted, or undeleted. There is no custom publisher that decides whether an event should exist. If the qualifying record change happens, the change stream reflects it.
That makes Salesforce Change Data Capture a strong fit for synchronization, search indexing, downstream caches, audit-oriented consumers, and other cases where the subscriber needs to know what changed in Salesforce. A CDC consumer can react regardless of whether the original change came from the UI, an API client, Flow, Apex, or another supported path. The business meaning can still be inferred downstream, but CDC itself is describing the data change.
The payload structure follows the source object. Salesforce explains that change event bodies correspond to the fields on the parent record. With the Salesforce Pub/Sub API, all record fields are present in the decoded schema, while unchanged values can be empty on updates and changedFields identifies what changed. This is an important correction to a common assumption: CDC is not a universal before-and-after snapshot. If a consumer needs old values for every changed field, it should keep its own prior state or retrieve history from another source designed for that purpose.
CDC adds transaction context that is valuable for replication. The ChangeEventHeader includes transactionKey, sequenceNumber, commitTimestamp, changeType, and changeOrigin. A subscriber can group changes from the same Salesforce transaction and use sequence information to understand their order within that transaction. changeOrigin can also help an integration detect changes created by its own API client and reduce feedback loops.
That richer source context is the main reason Salesforce Change Data Capture often beats a custom event for raw data replication. The publisher logic is already part of the platform, and the event describes the data mutation in the source system’s terms.
Platform Events vs Change Data Capture: Core Differences
The shortest useful Platform Events vs Change Data Capture comparison is this: Platform Events tell consumers that a defined event happened, while CDC tells consumers that Salesforce data changed. The rest of the architecture follows from that distinction.
| Decision Area | Platform Events | Change Data Capture |
| Event meaning | Business or integration event chosen by the publisher | Record mutation on a selected Salesforce entity |
| Publisher | Salesforce logic or an external application | Salesforce generates the event automatically |
| Schema owner | Your implementation team | Salesforce derives the event schema from the source object |
| Trigger condition | Explicit publish action | Create, update, delete, or undelete on an enabled entity |
| External publishing into Salesforce | Supported | Not applicable |
| Transaction metadata | Custom fields plus standard event fields | Built-in change header with transaction and change details |
| Best fit | Business signals, process milestones, cross-system commands or notifications | Replication, sync, cache or index updates, broad record-change awareness |
| Recovery model | Replay within retention plus application reconciliation | Replay within retention plus replication reconciliation |
A feature checklist can push a team toward the wrong semantics. The better Platform Events vs Change Data Capture test is whether the event can be named without mentioning a Salesforce record operation. InvoiceApproved is a business event. Invoice__c Updated is a change event. If the downstream requirement is really the first one, forcing consumers to reconstruct it from CDC creates coupling and repeated logic.
The reverse mistake is also common. Teams sometimes publish a custom Platform Event every time a record changes, recreating CDC by hand. That adds Apex or Flow logic, a custom contract, and another failure path without adding business meaning. CDC already exists for that problem.
Let Business Intent Drive The Choice
The cleanest selection rule starts with the consumer’s question. If the consumer asks, “What happened in the business process?” use an event whose name and fields answer that question. If the consumer asks, “What changed in Salesforce?” use a change stream that answers that question directly.
Consider a service case. A downstream customer communication system may need to know when a case is escalated. Several field edits could lead to that outcome: priority changes, entitlement checks, ownership changes, or a Flow decision. A Platform Event such as Case_Escalated__e gives the consumer 1 clear fact. The publisher can include only the case ID, escalation reason, severity, and timestamp needed by that subscriber contract. Salesforce Platform Events are a good fit because the event meaning is stronger than the database mutation that produced it.
Now consider a data warehouse that needs a current copy of Account and Contact data. It doesn’t care why BillingCity changed. It cares that the source record changed and that the warehouse should apply the latest values. CDC is the more direct model because it is tied to record mutations and includes change metadata without a custom publish layer.
A Salesforce event-driven architecture can use both patterns around the same business object. That isn’t duplication if each stream has a different purpose. CDC can feed the analytical replica while a Platform Event tells an order management system that an order is ready for dispatch. The Salesforce architecture guidance describes event producers and consumers as decoupled through message semantics, and that principle is easier to maintain when each event has one clear meaning.
When teams argue about Platform Events vs Change Data Capture based on personal familiarity with Apex, Flow, or middleware, the design usually gets harder to explain. Start with meaning, then choose the mechanism.
Compare Event Contracts And Payload Control
In the Platform Events vs Change Data Capture decision, payload control creates very different long-term costs. With Platform Events, your team decides which fields exist. That lets you create a narrow contract that protects consumers from internal Salesforce fields they don’t need. It also means your team must govern field names, required values, compatibility, and changes over time.
A small business event payload can be easier for external teams to understand because it carries only the information needed for the event. It can also reduce accidental coupling to Salesforce object design. If a subscriber only needs OrderNumber, ReleasedAt, and WarehouseCode, publishing those fields avoids exposing the full source record structure. Salesforce Platform Events make that contract possible, but the event owner must resist turning the event into a copy of the underlying object.
CDC takes the opposite approach. Its schema is tied to the source entity. In Pub/Sub API delivery, subscribers decode an Avro payload based on the event schema. Salesforce documents that the Salesforce Pub/Sub API can retrieve event schemas and uses schema IDs that change when the event schema changes. Consumers should therefore treat schema handling as part of the client design rather than hard-code assumptions forever.
CDC also carries fields that help a subscriber interpret updates. changedFields identifies changed fields, nulledFields identifies fields set to null in supported clients, and large text can involve diffFields. A consumer still needs a clear rule for applying partial changes and for fetching the current record when an event doesn’t contain enough detail for recovery.
For Platform Events vs Change Data Capture, ask who should own the contract. If the Salesforce integration team should publish a stable business interface, use Platform Events. If the consumer intentionally depends on Salesforce record structure because it is synchronizing that structure, CDC is usually the simpler contract.
Compare Replay And Delivery Recovery
Both event models use temporary retention rather than permanent messaging storage. Salesforce states that platform events and CDC events are retained for 72 hours. A subscriber can resume from a stored replay position while the needed events are still inside that window. Events older than the guaranteed window may be purged, so replay can’t replace a durable source-of-truth reconciliation process.
Replay IDs also need careful handling. They identify positions in an event stream, and Salesforce says they are opaque and aren’t guaranteed to be contiguous. A client should store the replay ID it last processed and use supported replay options when reconnecting. The Salesforce Pub/Sub API gives external consumers a single subscription interface for both event types, which can simplify client infrastructure without erasing the semantic differences between the event models.
CDC adds ordering information at the Salesforce transaction level. Change events are stored in the order their source transactions commit, and events from the same transaction share a transactionKey with different sequenceNumber values. Salesforce’s change event storage guidance explains that relationship between commit order, replay order, and transaction sequencing. Replication consumers can use those values to group related changes before committing them downstream.
Platform Event reliability needs a different guardrail. Salesforce documents an at-least-once asynchronous publishing model, which means a rare retry can produce a duplicate event with the same EventUuid and a different Replay ID. The Platform Event publishing considerations recommend subscriber-side duplicate handling. Consumers that perform non-idempotent actions, such as charging a card or creating a shipment, should use a business idempotency key or EventUuid strategy rather than assume one delivery equals one action.
The practical Platform Events vs Change Data Capture lesson is that replay is recovery assistance, not a full disaster plan. Keep checkpoints. Make consumers idempotent where repeated work would be harmful. Build a reconciliation path that can rebuild state after an outage longer than 72 hours.
Compare Volume And Operational Cost
Volume can change the right answer even when both event models are functionally possible. A CDC stream can become noisy if a selected object changes frequently and subscribers care about only a small fraction of those changes. A Platform Event can reduce that noise by publishing only the business moments consumers need, but it adds publisher logic and governance. The cost is therefore partly platform allocation and partly engineering work.
Salesforce says event delivery allocation for API subscribers is shared between high-volume Platform Events and CDC. The current default allocation documentation explains that delivery to Pub/Sub API, CometD, empApi, and event relays counts toward the 24-hour delivery allocation, while non-API subscribers such as Apex triggers and flows don’t consume that delivery allocation. Each external subscriber receiving an event contributes to delivered-event usage, so fan-out can multiply consumption even when the publish rate stays the same.
| Edition | Default Delivered Events In The Last 24 Hours |
| Performance and Unlimited | 50,000 |
| Enterprise | 25,000 |
| Developer | 10,000 |
These figures are documented defaults for the shared delivery allocation and can change with licensing or add-ons, so check the org’s current limits before sizing an integration. Salesforce also offers add-on capacity rather than a simple public per-event price, which means a dollar cost shouldn’t be invented during architecture planning. The useful estimate is expected events per day multiplied by the number of API subscribers that will receive them.
Filtering can reduce waste for both models. CDC supports custom channels with filter expressions for Pub/Sub API, CometD, and event relays. Salesforce explains that filtered CDC channels can reduce delivered events and make better use of delivery allocation. High-volume custom Platform Events also support filtered custom channels for supported external subscribers. This matters when the data model is correct but a subscriber needs only a subset of the stream.
For high internal Apex throughput, Platform Events have another option. Salesforce supports parallel subscriptions for Apex triggers on custom high-volume platform events, with up to 10 partitions per configured trigger. Change events aren’t supported by that feature. If heavy internal Apex processing is central to the design, this can influence the Platform Events vs Change Data Capture choice.
Choose The Right Subscription And API Pattern
For Platform Events vs Change Data Capture, external subscription design shouldn’t assume each model needs a separate transport stack. The Salesforce Pub/Sub API provides a common gRPC and HTTP/2 interface for subscribing to platform events and change events. Salesforce describes it as a single interface that uses binary Apache Avro event messages and supports flow control through the number of events requested by the client.
That common API is useful for integration teams because connection management, schema retrieval, replay handling, and client libraries can follow one pattern. The Salesforce Pub/Sub API introduction covers publishing Platform Events and subscribing to Platform Events and CDC through the same service. A team can standardize the transport code while still choosing event semantics separately for each use case.
The subscription pattern still changes by consumer. A replication consumer should persist its latest processed replay position and keep a reconciliation process for gaps or expired replay history. A business-event consumer should add idempotency around side effects and decide how failed business actions are retried. Transport doesn’t define the recovery rule.
Platform Events also let external systems publish messages into Salesforce. The Pub/Sub publishing guide explains that Publish and PublishStream return final publish results. That bidirectional role can be useful when an outside order system needs to notify Salesforce of a business event without writing directly to a Salesforce business object first.
CDC is one-way in a different sense: Salesforce is the source of the record-change notification. An external app doesn’t publish a CDC event to represent a remote record change. It updates Salesforce through an appropriate data API, and Salesforce may then emit CDC if that object is enabled.
Real-World Decision Scenarios
The best Platform Events vs Change Data Capture choice becomes clearer when the requirement is written as a subscriber outcome instead of a feature request. The following scenarios show how the same Salesforce data can lead to different event models depending on what the downstream system is trying to accomplish.
Data Warehouse Replication
A warehouse needs a current copy of selected Account, Contact, and Opportunity fields. It should catch changes regardless of whether they came from a sales rep, API integration, Flow, or Apex. CDC fits because the requirement is record synchronization. The consumer can use transactionKey and sequenceNumber when transaction grouping matters, store replay checkpoints, and periodically reconcile Salesforce against the warehouse.
The consumer should also handle gap and overflow conditions. Salesforce notes that CDC can send gap or overflow events when normal change details aren’t available. A replication design that assumes every event always contains enough record data will eventually have a recovery problem. The subscriber needs a path to re-read current source data when the stream says a gap occurred.
Order Fulfillment Signal
An external fulfillment service needs to start work only after an order passes validation and becomes releasable. A record may be edited several times before that point. Salesforce Platform Events fit because the subscriber wants a business milestone, not every order mutation. The publisher can emit Order_Released__e after the qualifying transaction commits and include the identifiers the fulfillment service needs.
The publication rule becomes part of the Salesforce business process, so subscribers receive the same declared event without reconstructing the meaning from record fields.
Search Index Refresh
A search service mirrors product or knowledge records from Salesforce and must refresh entries when indexed fields change. CDC is usually the better base because the task is keeping an external representation aligned with source records. If event volume is high and only certain field changes matter, a filtered CDC channel may reduce unnecessary deliveries for supported external subscribers.
The indexer can apply the event or retrieve the latest record. Re-reading current state is useful after gaps or closely spaced updates, so the event can act as an invalidation signal rather than the only copy of the record.
Cross-System Business Workflow
A billing system, ERP, and notification service need to react when Salesforce approves a contract. The contract record itself may have dozens of fields, but each subscriber only needs a small set of identifiers and business facts. Platform Events are usually clearer here because the event represents Contract_Approved, not “Contract changed.”
This is a common Salesforce event-driven architecture pattern: Salesforce publishes one business fact and several consumers react independently. New consumers can subscribe later without changing the original transaction, provided the event contract already contains what they need or a compatible versioning plan exists.
Echo-Prone Bidirectional Sync
An external master-data service updates Salesforce, and Salesforce changes can flow back to the service. CDC is useful because changeOrigin can identify API-originated changes when the client ID is supplied, helping the consumer avoid processing its own write as a new independent change. That doesn’t remove the need for conflict rules, but it provides source information that a custom event would have to carry explicitly.
If the external system also needs to tell Salesforce about business milestones that aren’t direct Salesforce record mutations, add Platform Events for those milestones rather than stretching CDC into a general command channel.
When A Hybrid Event Model Makes Sense
A Platform Events vs Change Data Capture hybrid design is appropriate when a Salesforce estate has both replication needs and business-event needs. The mistake is using both for the same semantic purpose without a clear boundary. A hybrid model should separate streams by meaning so consumers know which source is authoritative for each type of message.
One common pattern uses Salesforce Change Data Capture for analytical or operational replicas and Salesforce Platform Events for business workflows. The warehouse subscribes to Account and Opportunity changes. An order service subscribes to Order_Released__e. A customer communication service subscribes to Case_Escalated__e. They can share the Salesforce event bus while keeping different contracts.
Another hybrid pattern uses CDC as an internal observation stream and publishes a smaller business event only after Salesforce logic validates a condition. For example, CDC may tell an integration service that Opportunity data changed, while a Flow or Apex path publishes Renewal_Ready__e once the business rules are satisfied. This approach is useful when the business state can’t be represented by 1 raw field mutation.
Keep the handoff rule explicit. Don’t subscribe to CDC and then publish a near-identical Platform Event just to rename the message unless there is a real contract boundary, filtering need, or business interpretation step. Otherwise you add another hop and another place to fail without changing the meaning.
For Platform Events vs Change Data Capture in a hybrid architecture, document which stream answers which question. CDC should answer what changed in Salesforce. Platform Events should answer what business fact a publisher chose to announce. That separation makes ownership and recovery easier to reason about.
Conclusion: A Practical Selection Rule
The Platform Events vs Change Data Capture decision is mainly a decision about meaning and ownership. Use Platform Events when a producer should declare a business event through a contract your team controls. Use CDC when a consumer needs Salesforce record changes with source transaction context and automatic publication.
Then test the choice against production concerns. Check whether the consumer needs transaction grouping, whether it can tolerate duplicate delivery, how it will recover after 72 hours, how many external subscribers will consume the shared delivery allocation, and whether filtering or parallel Apex processing matters. Those questions can change implementation details without changing the event’s meaning.
A good Salesforce event-driven architecture keeps event meaning explicit and rarely tries to force every integration through one message type. A mature Salesforce event-driven architecture can use both models without blurring their contracts. Keep record replication and business signaling distinct. Use the Salesforce Pub/Sub API as a common external transport where it fits, but let the event semantics decide whether Platform Events or Salesforce Change Data Capture owns each use case.
FAQs
What Is The Main Difference Between Platform Events And Change Data Capture?
Platform Events are explicitly published messages with a schema your team defines. Change Data Capture events are generated automatically when enabled Salesforce records are created, updated, deleted, or undeleted. The practical difference is intent: Platform Events usually represent a business fact, while CDC represents a source-record mutation.
Is CDC Better Than Platform Events For Data Replication?
CDC is usually a better starting point for replication because it is tied directly to Salesforce record changes and includes change and transaction metadata. A replication consumer still needs replay checkpoints, idempotent processing, and a reconciliation process for gaps or outages that exceed the retention window.
Can Platform Events Replace Change Data Capture?
They can reproduce some change-notification use cases, but doing so often means writing custom publish logic for events Salesforce could generate automatically through CDC. Platform Events are more useful when the message needs a business meaning or a custom contract rather than a direct copy of record-change semantics.
Can Change Data Capture Replace Platform Events?
CDC can’t fully replace Platform Events when a process needs to publish a business event that isn’t the same thing as a record mutation. A consumer shouldn’t have to infer PaymentReceived or OrderReleased from several fields if Salesforce can publish that business fact directly.
Do Platform Events And CDC Use The Same Event Bus?
Yes. Both are carried through the Salesforce event bus and share event-delivery concepts such as replay. That shared transport doesn’t make their contracts identical. Platform Events use a publisher-defined schema, while CDC is tied to the Salesforce record and its change metadata.
How Long Are Salesforce Events Retained For Replay?
Salesforce documents a 72-hour retention window for Platform Events and Change Data Capture events. Subscribers can replay events that remain inside that window. A production integration should still have a reconciliation path because an outage can last longer than the guaranteed retention period.
Does Change Data Capture Include Old And New Field Values?
CDC shouldn’t be treated as a universal before-and-after payload. Change events provide current change information and metadata such as changedFields; unchanged fields can be empty in update messages. A consumer that needs reliable old values should keep prior state or use another source designed to preserve history.
Can External Systems Publish Change Data Capture Events?
No. CDC events are generated by Salesforce in response to qualifying Salesforce record changes. An external system can update Salesforce through a data API, and that record change can then produce a CDC event if the entity is enabled.
Can External Systems Publish Platform Events Into Salesforce?
Yes. External applications can publish custom Platform Events through supported Salesforce APIs, including Pub/Sub API. This makes Platform Events useful when a business event originates outside Salesforce but Salesforce subscribers need to react to it.
Which Model Is Better For A Business Milestone Such As Order Released?
Platform Events are usually clearer because the event can directly represent OrderReleased and carry the fields subscribers need. CDC would tell subscribers that an order record changed, leaving them to determine whether that change actually means the order was released.
Which Model Is Better For Keeping A Search Index Current?
CDC is often the simpler choice because the search index needs to know that source records changed. The consumer can update or re-read affected records. If only a subset of changes matters, a filtered change channel can reduce the amount of data delivered to supported external subscribers.
How Do Replay IDs Affect The Choice?
Replay IDs support recovery for both models, so replay alone usually doesn’t decide between them. Subscribers should store the latest processed replay position and treat it as a stream checkpoint. They shouldn’t use a Replay ID as a permanent business identifier or assume replay history lasts beyond the retention window.
Can Platform Event Subscribers Receive Duplicate Messages?
Yes. Salesforce documents an at-least-once publishing model for asynchronous Platform Events, so rare duplicate publications can occur. Consumers that create side effects should use idempotency controls and stable identifiers so processing the same business event again doesn’t create a duplicate business action.
Do CDC Events Preserve Salesforce Transaction Order?
CDC provides transaction metadata that helps consumers preserve source transaction meaning. Events from the same transaction share a transactionKey, and sequenceNumber identifies their order within that transaction. This is especially useful for replication consumers handling multi-record business operations.
When Should A Team Use Both Platform Events And CDC?
Use both when the architecture has 2 distinct needs: record-change synchronization and business-event signaling. Keep the responsibilities separate. CDC can feed replicas or indexes, while Platform Events can notify other systems about business milestones that shouldn’t be inferred from raw record changes.
