The Choice That Isn’t Really About Technology
When an organization starts discussing Event-Driven Architecture in Salesforce, the conversation often too quickly veers towards "Platform Events or CDC?"—as if it's solely a tools question. In reality, it's a completely different inquiry: which side of the integration is the source of truth, what can it afford to lose, and who bears the cost when a message arrives late, duplicated, or not at all.
The short answer: Change Data Capture (CDC) is suitable when an external system needs to know that Salesforce updated a row, and there's no need to wrap that in business logic. Custom Platform Events are ideal when you want to publish a meaningful business event—"customer upgraded plan," not "Status_c field changed." The wrong choice isn't apparent on launch day; it becomes clear when someone needs to reconstruct what happened after a partial failure and discovers there's no reliable way to know.
For a broader perspective on Salesforce integrations beyond events, refer to the CRM Architecture Guide.
Three Questions That Define Architecture Before Writing a Line of Code
Before choosing a mechanism, you need answers to three questions. Skipping any of them is the most common reason integration projects get stuck in the testing phase.
Who owns the data? If Salesforce is the source of truth for the customer record, outbound events from Salesforce (Platform Events or CDC) are the natural direction. If the ERP system is the owner, the opposite is true, and Salesforce should consume events rather than publish them for that same entity.
What can be lost? An alert to an executive dashboard can lose a single message without harm. A credit limit update before transaction approval cannot. This distinction determines whether a "fire-and-forget" approach is sufficient or if an acknowledgment and reconciliation mechanism is required.
What happens if the message arrives twice? Platform Events guarantee At-Least-Once, not Exactly-Once. If the answer is "we don't know"—the solution isn't production-ready, regardless of how clean the code is.
Platform Events vs. CDC — Decision Table
| Criterion | Custom Platform Event | Change Data Capture |
|---|---|---|
| What is Published | Defined business event (custom payload) | Raw row change (before/after) |
| Who Builds the Logic | Salesforce developer, during Trigger or Flow | The platform, automatically for any defined DML |
| Schema Coupling | Low — payload is controlled by the publisher | High — any change to the object structure affects the consumer |
| Suitable When... | You want to publish business intent ("Order Approved") | You want raw data synchronization between systems |
| Maintenance Cost | Higher initially (building payload and logic) | Lower initially, higher when object structure changes |
| Retention | Based on license definition (hours to days) | Based on license definition, often same as Platform Events |
| Recommended Volume | Medium-frequency domain events | Row-level changes, including high frequency |
Practical rule of thumb: If the event consumer needs to understand "why" it happened, not just "what" happened, then a custom Platform Event is necessary. If the consumer merely needs an updated copy of the data, CDC saves an entire development layer.
Ordering, Replay, and Idempotency: The Three Concepts That Turn Theory into Stable Production
These are not topics for the late stages of a project—they dictate the consumer's structure from day one.
Ordering. Platform Events are sent in publication order within the same topic, but load and partial failures can disrupt the reception order on the consumer side. Practical solution: include a version stamp or sequence number from the original record with each event, and allow the consumer to reject an event whose version is older than the last one already processed.
Replay. Each event receives a Replay ID. A consumer that crashes should store the last successfully processed Replay ID—not in memory, but in persistent storage (Custom Object, external table)—and resume from there during recovery. Relying on "the system will start from scratch" only works within the retention window, and beyond that, events are lost.
Idempotency. Every consumer needs to identify an already processed event, typically by a unique transaction ID sent within the payload. Without this, automatic retries on the sender side—or manual replay after a failure—result in double updates, duplicate record creation, or in the worst case, double billing.
This gap almost never shows up in a demo. It emerges under load, during an actual network failure, or a change in the production environment, and by then, the cost to fix it also includes data correction. Organizations encountering a similar issue in their automation layer can find a complementary analysis in Salesforce Flow and Apex Technical Debt.
Example Scenario: Retail Chain with 40 Branches and Separate Inventory System
Consider a hypothetical retail chain, "North Retail," operating Salesforce Sales Cloud for sales teams across 40 branches, and a separate ERP system managing real-time inventory. Until now, every order closed in Salesforce was transferred to the ERP via a scheduled job running every 15 minutes—a solution that sometimes led to sales reps seeing outdated inventory and approving orders for out-of-stock products.
The architecture team decided to publish a custom Platform Event named Order_Confirmed__e upon every order confirmation, with a payload that includes a unique transaction ID, item list, and quantities. The ERP listens for the event and updates inventory within seconds, checking the transaction ID against a table of already processed transactions—to prevent double deduction if the event arrives twice.
Additionally, a nightly reconciliation process was established to compare the total orders confirmed in Salesforce with the total updates received in the ERP, alerting to any discrepancy above a defined threshold. The reason: even with proper idempotency, early detection of extended network failures is desired, rather than solely relying on the event "surely arriving." The result: update time dropped from 15 minutes to less than a minute, and the number of incorrect inventory incidents measurably decreased within one month of implementation.
This scenario illustrates a key principle: value isn't created merely by "moving to events" itself, but by combining a clear business event, duplicate checking on the consumer side, and a monitoring process that identifies discrepancies before they become customer complaints.
Common Risks and Preventive Actions
| Risk | How it Manifests | Preventive Action |
|---|---|---|
| Publishing an event for every field change | Daily event limits exceeded within days | Publish meaningful business domain events, not technical events for every DML |
| No duplicate checking on the consumer side | Retries or replays create duplicate records or updates | Include a unique transaction ID and check it before any action |
| Reliance on arrival order | An older update overwrites a newer update | Include a version stamp and reject events older than the last processed version |
| No Replay ID persistence | After consumer crash, events between crash and retention window are lost | Store Replay ID persistently and implement automatic replay upon restart |
| CDC on an frequently changing object structure | Every field change breaks the external consumer without warning | Define an explicit data contract and communicate schema changes in advance |
| No business monitoring, only technical monitoring | Integration is "green" but actual inventory or orders don't match | Add daily reconciliation that compares business outcomes between systems |
Checklist Before Starting Event Layer Development
- ☐ Each event has a clear owner: who publishes and who is the business owner of the data
- ☐ A consistent and documented payload is defined, not a structure that changes with every sprint
- ☐ A choice has been made between custom Platform Events and CDC based on business intent versus raw change
- ☐ Each consumer has a unique transaction ID and duplicate checking (Idempotency)
- ☐ Order handling is defined by version stamp, not by arrival order
- ☐ Replay ID is stored persistently, and a recovery process is defined and tested
- ☐ Business monitoring (Reconciliation) exists in addition to technical message queue monitoring
- ☐ Load and partial failure scenarios have been tested, not just the happy path
- ☐ Daily event limits (Publish + Delivery) have been checked against expected production volume
- ☐ An operational owner is defined to respond when a reconciliation discrepancy is found
How to Measure Architecture Effectiveness
| Area | What to Measure | Measurement Frequency |
|---|---|---|
| Delivery Reliability | Percentage of events completed without retry, and percentage successful after retry | Continuous |
| Reconciliation Discrepancies | Difference between records confirmed in source and records received in target | Daily |
| End-to-End Latency | Time from business event to actual update at the consumer | Continuous |
| Event Limit Utilization | Percentage of daily quota actually used | Weekly |
| Duplicates Prevented | Number of events identified as duplicates and blocked before execution | Weekly |
It's recommended to choose no more than three to four metrics for the initial version and measure them against a baseline collected before transitioning to event architecture—not against a general feeling that "it's faster now."
For broader organizational planning of multiple integrations, also consider Salesforce Integration Patterns and their implications for Single Org vs. Multi Org Architecture, as event decisions often cross organizational boundaries.
Summary
The choice between Platform Events and CDC is not a short-term technical question at the project's start—it determines the source of truth, what can be lost, and how the system behaves when something goes wrong in the middle. An organization that plans ordering, replay, and idempotency in advance, and adds a business reconciliation layer in addition to technical monitoring, achieves an integration that withstands load and partial failure. An organization that skips these steps gets a system that looks fine in testing but silently breaks in production, usually without anyone noticing until the damage is already done.
Organizations seeking guidance in building a reliable event layer in Salesforce can reach out through our CRM Architecture service.