Platform Events vs Change Data Capture vs Streaming API: The 2026 Event-Driven Salesforce Guide

TL;DR

• Platform Events — you define the schema and publish on demand. Use for custom business events ("OrderApproved", "RiskDetected").
• Change Data Capture (CDC) — Salesforce auto-publishes record changes for opted-in objects. Use for mirroring data to external systems.
• Streaming API (Push Topic, Generic Streaming) — the legacy mechanism. Replaced by Platform Events + CDC. Use only for backward compatibility.
• The decision: do you control the schema (Platform Event), do you want every record change (CDC), or are you maintaining old code (Streaming API)?

Sales orgs in 2026 are event-driven by default. Order is approved → notify warehouse, log to data warehouse, kick off Marketing Cloud journey, alert account manager. None of that is one trigger; it's a pub/sub event reaching multiple subscribers.

Salesforce ships three event mechanisms. They look similar from the outside; they're built for different jobs. This guide is the 2026 decision matrix.

Why event-driven Salesforce?

Triggers don't scale across systems. A trigger on Account update can do something inside Salesforce — log a record, update a field, queue an async job. It cannot reliably tell external systems about the change.

Event-driven architecture solves that:

• Loose coupling. The publisher doesn't know who subscribes.
• Multiple subscribers. Same event can fan out to a warehouse, a CDP, an email engine.
• Durable delivery. Subscribers can replay missed events.
• No DML coupling. Publishing is non-blocking; subscribers can fail without rolling back the publisher.

In practice, almost every modern Salesforce architecture has at least one of: Platform Events for business events, CDC for data sync, or both.

The three mechanisms at a glance

Platform Events

Platform Events are custom event types you define, like a custom object — but instead of being stored as records, they're streamed.

Defining a Platform Event

Setup → Platform Events → New Platform Event:

• API name (e.g., Order_Approved__e)
• Custom fields (Text, Number, Date, etc. — most field types except formulas/lookups)
• Publish behavior — "Publish After Commit" (default, transactional) or "Publish Immediately" (non-transactional)

The __e suffix marks it as a Platform Event.

Publishing

Order_Approved__e evt = new Order_Approved__e(
  Order_Id__c = order.Id,
  Approved_By__c = UserInfo.getUserId(),
  Approved_At__c = System.now()
);
Database.SaveResult sr = EventBus.publish(evt);

You can also publish from:

• A Flow — "Create Records" element on the Platform Event.
• A REST API — POST /services/data/v60.0/sobjects/Order_Approved__e/.
• Process Builder (legacy).

Subscribing

Three subscriber types:

1. Apex trigger — write a trigger on the Platform Event:

trigger OrderApprovedHandler on Order_Approved__e (after insert) {
  for (Order_Approved__e evt : Trigger.new) {
    // process the event
  }
}

1. Flow — record-triggered flow with "Platform Event Message" type.

2. External subscriber — via the Pub/Sub API (gRPC) or CometD-based Streaming API.

Publish-after-commit vs publish-immediate

• After commit (default). The event is published only when the parent transaction commits. If the transaction rolls back, the event is never sent. Safe and transactional.
• Immediate. The event is published as soon as EventBus.publish() is called, even if the transaction later rolls back. Use sparingly — useful for logging events that need to survive failures.

Change Data Capture

CDC fires events automatically whenever a record changes on an opted-in object. No publishing code; you just consume.

Enabling CDC

Setup → Change Data Capture → check the boxes for objects you want.

You can opt in standard objects (Account, Contact, Case, Opportunity) and custom objects.

What CDC events contain

Each event includes:

• The change type (CREATE, UPDATE, DELETE, UNDELETE)
• A subset of fields — what changed, plus required identifiers
• The change timestamp
• A replay ID

You don't get the full record — you get only the changed fields plus identifiers. Subscribers either query for more, or store enough state to apply the diff.

Subscribing to CDC

Same options as Platform Events:

trigger AccountChangeHandler on AccountChangeEvent (after insert) {
  for (AccountChangeEvent evt : Trigger.new) {
    EventBus.ChangeEventHeader header = evt.ChangeEventHeader;
    // header.recordIds — the IDs that changed
    // header.changeType — CREATE/UPDATE/DELETE/UNDELETE
    // header.changedFields — array of field names
  }
}

External subscribers consume via the Pub/Sub API.

When to pick CDC

• Mirroring Salesforce data into a warehouse, lake, or CDP.
• Cache invalidation in external systems.
• Real-time analytics that read off Salesforce changes.
• Any case where "tell me when X changed" matters more than "tell me X happened."

When NOT to pick CDC

• You need a custom business event that isn't a 1:1 record change. Use a Platform Event.
• You need richer payloads than what CDC gives you.
• You need filtering beyond opt-in object level. CDC fires on every change; subscribers filter.

Streaming API (legacy)

The original streaming mechanism. Two flavors:

Push Topic

A SOQL query that defines what to stream:

SELECT Id, Name, AnnualRevenue FROM Account WHERE AnnualRevenue > 1000000

Whenever a matching record changes, an event fires. CometD subscribers receive it.

Why Push Topic is mostly dead:

• Limited to a SOQL filter; not suitable for real business events.
• Replaced by CDC for record changes (more reliable, broader fields).
• Replay buffer is limited (24 hours).
• No transactional publish-after-commit semantics.

Generic Streaming

Custom event types published via REST. The schema is untyped — you decide.

Why Generic Streaming is mostly dead:

• Replaced by Platform Events (typed, more features, more subscribers).
• Same 24-hour replay buffer.
• No Apex subscriber.

Use Streaming API only for backward compatibility with existing CometD integrations. New work should be Platform Events or CDC.

Subscription patterns

How you consume events shapes your architecture.

Apex trigger subscriber

Same model as a normal trigger. Runs in the publisher's org, consumes the event, applies async logic.

Pros:

• Native to Salesforce.
• Full Apex available — DML, callouts, etc.

Cons:

• Counts against your Apex async limits.
• Errors require careful handling — failed Apex doesn't roll back the publish.

Flow subscriber

A record-triggered flow on the Platform Event Message type. Same constraints as the trigger but with admin-friendly authoring.

Best for: simple business logic, notifications, field updates.

Pub/Sub API (gRPC)

The modern external subscriber. Salesforce's recommended way for external systems to consume events.

• gRPC, binary protocol, higher throughput than CometD.
• Supports publishing too, not just subscribing.
• Replay support up to 3 days for Platform Events, 3 days for CDC.
• Single connection consumes from multiple events.

If you're building a new external integration, use Pub/Sub API.

CometD (Streaming API)

The legacy long-polling mechanism. Still works for Platform Events and CDC, but limited:

• Older protocol; less efficient than gRPC.
• Lower replay limits.
• Still common in MuleSoft and older middleware.

MuleSoft connector

MuleSoft has first-class connectors for Platform Events and CDC. Most enterprise teams using MuleSoft consume events through those connectors rather than rolling their own.

Replay IDs and durability

The hard problem: what if a subscriber goes down for an hour and misses events?

Salesforce assigns each event a replay ID (a 24-byte identifier). Subscribers can:

• Replay from a specific ID to catch up.
• Replay from the start of the buffer (-2).
• Replay from now (-1, default).

Buffer windows:

• Platform Events: 3 days of replay history.
• Change Data Capture: 3 days.
• Push Topic / Generic Streaming: 24 hours (legacy, more limited).

If your subscriber misses more than the buffer window, you've lost events. The defensive pattern is to store the last successfully processed replay ID in your subscriber, and resume from there.

For longer-than-3-day durability, push events into a long-term store (Kafka, S3, Big Object) immediately on receipt.

Limits

The numbers that matter.

Daily limits are the most common surprise. A noisy event ("ButtonClicked") published per click can blow through 1M/day in a small org. Be selective about what's eventized.

When to pick which — the decision matrix

Need a custom business event you control? → Platform Event.

Need to mirror Salesforce data to an external system? → CDC.

Need every change to a specific object, with full record context? → CDC + Apex trigger that re-queries.

Building a new external subscriber? → Pub/Sub API consuming Platform Events or CDC.

Maintaining a legacy CometD subscriber that already works? → Leave it on Streaming API; migrate when you next touch it.

Need durable, replayable event log for analytics? → CDC + push to Kafka/S3 within the 3-day buffer.

Patterns that work

Pattern 1: Business event for cross-system orchestration

You define Order_Approved__e. The Apex that approves the order publishes it. Subscribers:

• Apex trigger updates the warehouse system via callout.
• Flow updates a field on a related Opportunity.
• External MuleSoft flow updates the ERP.
• External Marketing Cloud listener fires a journey.

One publisher, four loosely coupled subscribers. Add a fifth tomorrow without touching the publisher.

Pattern 2: CDC into Snowflake

Enable CDC on Account, Contact, Opportunity. A Pub/Sub API consumer (running in your data platform) picks up events and writes to Snowflake. Near-real-time mirror of Salesforce records.

For high-volume orgs, batch the writes (commit every 1k events or every 5 seconds, whichever first).

Pattern 3: Hybrid — CDC for sync, Platform Event for action

Use CDC for what changed (data mirroring) and a separate Platform Event for what happened ("OrderApproved" carries semantic meaning that "Order changed" doesn't). Both can flow into the same downstream pipeline.

Common pitfalls

• Pattern 1: Eventizing every change. Just because you can publish an event doesn't mean you should. Each event burns delivery quota and consumes processing.
• Pattern 2: Trusting CDC with full record state. CDC gives you the changed fields — not the full record. If your subscriber needs full state, query for it.
• Pattern 3: Publish-immediate when after-commit was right. Causes phantom events on rolled-back transactions. Use after-commit unless you have a specific reason.
• Pattern 4: No replay ID checkpointing. If your subscriber goes down without storing its last replay ID, you'll either miss events or reprocess from the start.
• Pattern 5: One giant Platform Event for everything. A Generic_Event__e with a JSON blob "type" field is an anti-pattern. Use typed events; you'll thank yourself.
• Pattern 6: Apex subscriber doing slow work synchronously. Subscriber Apex still has limits. Hand off to a Queueable for anything heavy.
• Pattern 7: Forgetting CDC counts toward the same daily limit. A noisy CDC topic can drain your Platform Events budget unexpectedly.
• Pattern 8: Treating Streaming API as future-proof. Push Topics and Generic Streaming are legacy. New code goes Platform Events or CDC.
• Pattern 9: No DLQ. Failed event processing should write to a Dead Letter Queue (custom object or external store). Otherwise failures vanish.
• Pattern 10: Cross-region latency assumptions. Pub/Sub API is region-pinned. If your subscriber lives in a different region, factor in network latency.

How Agentforce uses events (2026)

Agentforce is event-aware. Common patterns:

• Agent triggered by an event. "Account churn risk score crossed threshold" → Platform Event → triggers an agent that drafts a save-attempt email.
• Agent publishes events. Agent action publishes Customer_Outreach_Sent__e so downstream systems can audit.
• CDC powers Data 360 ingestion. Data 360's near-real-time sync of Salesforce records uses CDC under the hood.

Critical: events from agents need their own audit trail. Don't let agent-published events look identical to user-published events — add an originator field.

Frequently asked questions

Can I publish a Platform Event from a batch Apex job? Yes. Standard EventBus.publish() works in async context.

Does CDC fire on Bulk API uploads? Yes — every record change fires a CDC event, including bulk operations. This is a common surprise that triggers daily-limit alerts.

Can I rate-limit Platform Events? Not natively. Throttle in your publisher code (e.g., aggregate before publishing).

What's the difference between Platform Events and Big Object? Platform Events are streams (transient, replayable for 3 days). Big Objects are storage (durable, queryable). Some architectures pair them — publish events, also write to Big Object for long-term audit.

Can the same Apex trigger subscribe to both Platform Events and CDC? No — triggers are object-specific. You'd have one trigger per event type.

Do Platform Events count against API call limits? No — they have their own delivery quotas separate from REST/SOAP API limits.

What's the recommended way to consume events from outside Salesforce in 2026? Pub/Sub API. CometD still works but is no longer the recommended path for new builds.

What to read next

• Platform Event, Change Data Capture — the dictionary entries.
• Async Apex Complete Guide — what your event subscribers should hand work off to.
• Salesforce Governor Limits Cheat Sheet — limits your event volumes need to fit inside.

Pick by source: custom business event = Platform Event, record change = CDC, legacy CometD = Streaming API. New external subscribers go Pub/Sub API. Always checkpoint your replay IDs.