Event-Driven Integration in Salesforce: Using Change Data Capture and Platform Events Effectively

Enterprise platforms today operate within increasingly complex digital ecosystems where multiple systems must exchange information continuously. Traditional integration approaches—such as batch data transfers or scheduled polling—often introduce delays, unnecessary resource consumption, and tight dependencies between systems. As transaction volumes grow and system landscapes expand, these approaches can become difficult to scale and maintain.

Event-driven architecture offers a more efficient alternative. Instead of systems repeatedly checking whether something has changed, events are generated whenever meaningful activity occurs, and interested systems subscribe to those events. This approach allows applications to react in near real time while remaining loosely coupled from one another.

Within Salesforce, the Event Bus provides the infrastructure that enables this architectural pattern. Two key mechanisms that support event-driven integration are Change Data Capture (CDC) and Platform Events. While both rely on the same event streaming foundation, they serve different purposes within an integration architecture. Understanding how they complement each other—and how they can be used together—helps create more resilient and scalable systems.

Data Changes and Business Events in Integration Design

In most enterprise integrations, two types of signals typically need to flow between systems. The first involves changes to data, where downstream platforms must update their records to stay consistent with Salesforce. The second involves business-level events, where systems must respond to an operational milestone or workflow step.

Salesforce addresses both needs through CDC and Platform Events.

Change Data Capture automatically publishes events whenever records are created, updated, deleted, or restored. These events provide detailed metadata about the change, including the fields that were modified and the transaction details. Because this publishing process happens automatically, CDC acts as a reliable mechanism for streaming data updates as they occur.

Platform Events, on the other hand, allow applications to publish messages that represent meaningful activities within a business process. These events are defined using custom schemas and are published intentionally through application logic or automation processes. The result is a publish–subscribe model where multiple systems can respond to the same event independently.

In practice, both types of events often coexist within the same architecture, each serving a different role.

Example: Synchronizing Operational Data

Consider an organization that uses Salesforce as its primary platform for managing customer accounts and opportunities while maintaining a centralized data warehouse for reporting and analytics.

Whenever a new account is created or an opportunity is updated, the data warehouse must reflect those changes to ensure reporting accuracy. Instead of running periodic data exports, the warehouse subscribes to change events generated by Change Data Capture. When a record changes, Salesforce publishes an event describing the update, and the data pipeline processes that event to update the corresponding record in the warehouse.

In this scenario, the primary objective is to keep two systems synchronized. CDC provides the necessary information about what changed so that downstream systems can update their data stores accordingly.

However, suppose that when an opportunity is marked as closed, several additional actions must occur across different systems. The organization may need to generate invoices, initiate customer onboarding processes, and notify internal teams. Rather than relying on multiple point-to-point integrations, the system can publish a Platform Event indicating that the deal has been finalized.

Each interested system subscribes to this event and performs its own processing. The billing system generates invoices, the provisioning system activates services, and the analytics platform records the milestone. In this case, the event communicates not just that data changed but that a meaningful business outcome occurred.

Example: Order Processing Across Systems

A similar pattern can appear in order management workflows. When an order record is updated in Salesforce, Change Data Capture may publish an event reflecting that update. Systems that maintain synchronized order data—such as inventory platforms or reporting systems—can consume this event to keep their records aligned.

At the same time, certain status transitions within the order lifecycle may represent important operational milestones. When an order moves from processing to confirmed, for instance, a Platform Event can be published to signal that the order is ready for fulfillment.

Multiple downstream systems may respond to this single event. A logistics platform might initiate shipment preparation, a billing system might generate an invoice, and a customer notification service might send a confirmation message. Because these systems subscribe to the event rather than being directly invoked, they remain loosely coupled and easier to maintain.

Example: Customer Support Ticket Workflow

A similar event-driven pattern can be applied in customer support workflows. When a new support ticket is created in Salesforce, Change Data Capture can publish an event reflecting the creation of the ticket. Downstream systems—such as a knowledge base, analytics platform, or a customer portal—can consume this event to update their records and maintain synchronized information.

At the same time, certain ticket status changes within the support lifecycle represent meaningful operational milestones. For example, when a ticket moves from “Open” to “Escalated,” a Platform Event can be published to signal that the ticket requires specialized attention. Multiple systems may respond to this event independently: the escalation management system assigns the ticket to a specialized team, the customer portal updates the ticket status, and an analytics system logs the milestone for reporting purposes.

In a bi-directional scenario, downstream systems can also publish Platform Events back to Salesforce or other connected systems. For instance, if the escalation management system resolves the ticket, it can publish a “Ticket Resolved” Platform Event. Salesforce receives this event and updates the ticket status, triggers automated customer feedback surveys, and notifies the support team. Other connected systems, such as reporting dashboards or billing systems, can also consume the same event to update analytics or close related service tasks.

This two-way event flow allows all systems to remain synchronized, respond to milestones in real time, and remain loosely coupled. By using Platform Events in both directions, organizations can create a fully integrated, responsive support ecosystem without building complex point-to-point integrations.

Integration Use Cases in Practice

In many organizations, Change Data Capture becomes the backbone for data synchronization scenarios. Data warehouses, search platforms, operational databases, and analytics pipelines often subscribe to change events to ensure that they maintain an up-to-date representation of Salesforce data.

Platform Events, meanwhile, are frequently used in process-driven integrations. Whenever a business milestone occurs—such as an order confirmation, a completed onboarding process, or a service activation—an event can be published to notify other systems that the next stage of the workflow should begin.

These two mechanisms naturally complement each other. CDC communicates changes at the data layer, while Platform Events communicate progress within a business process.

Integration Platforms: MuleSoft and Other Middleware Tools

In many enterprise environments, Salesforce is not integrated directly with every downstream system. Instead, an integration platform or middleware layer is used to manage communication between applications, transform data formats, and orchestrate workflows.

One commonly used integration platform is MuleSoft, which provides capabilities for API management, message routing, and event processing. MuleSoft can subscribe to Salesforce Change Data Capture events and Platform Events, distributing them to other systems such as ERP platforms, data warehouses, or microservices. This allows organizations to centralize integration logic while still benefiting from real-time event streams.

Importantly, integration platforms also enable bi-directional communication. Downstream systems can send updates, events, or messages back through MuleSoft to Salesforce or to other connected systems. For example, an ERP system may update order fulfillment status, which is routed back to Salesforce to trigger workflows or publish Platform Events for other services. Similarly, a data warehouse may trigger alerts or updates that flow through the integration layer to multiple operational systems.

Other integration technologies can support similar patterns. Messaging systems such as Apache Kafka, cloud integration services like Azure Integration Services or AWS EventBridge, and enterprise service buses can all facilitate both inbound and outbound event flows, creating a fully connected, two-way integration ecosystem.

By introducing a bi-directional integration layer, organizations gain additional flexibility. Middleware platforms can handle data transformation, error handling, retry logic, and routing rules for events moving in both directions without embedding those responsibilities directly within Salesforce. This separation maintains clean boundaries between systems while enabling scalable, event-driven communication across the enterprise.

Rule of Thumb for Integration Design

A practical guideline when designing event-driven integrations is to focus on the intent of the message being communicated.

If the primary goal is to inform other systems that a record has changed, then Change Data Capture is typically the most appropriate approach. The event contains the detailed metadata necessary for systems to replicate or update the data.

If the goal is to communicate that a meaningful activity or milestone has occurred, then Platform Events are generally more suitable. These events capture the business context and allow multiple systems to react independently.

Another way to frame this distinction is that CDC focuses on state changes, while Platform Events focus on process events.

Combining CDC and Platform Events in a Layered Architecture

Many mature integration architectures combine both approaches. Change Data Capture provides the foundational stream of record updates, while Platform Events represent higher-level signals derived from those changes.

For example, when a record is updated, CDC publishes an event describing the modification. An integration service or application layer may interpret this update and determine that it represents a specific business milestone. At that point, a Platform Event can be published to communicate that milestone to other systems.

This layered approach separates the responsibilities of data propagation and workflow coordination, allowing each part of the architecture to evolve independently.

Conclusion

Event-driven integration patterns provide a scalable way for systems to exchange information in real time without creating tight dependencies between applications. Within Salesforce, Change Data Capture and Platform Events provide complementary capabilities that support this architectural model.

CDC enables the continuous streaming of record-level changes, ensuring that external platforms remain synchronized with Salesforce data. Platform Events allow applications to communicate meaningful activities within a business process, enabling distributed systems to coordinate workflows efficiently.

When used together—and when supported by integration platforms such as MuleSoft or other middleware technologies—these mechanisms help create architectures that are responsive, maintainable, and capable of supporting complex enterprise system landscapes.

Disclaimer

Salesforce®, MuleSoft®, AWS®, Azure®, and other product names are trademarks of their respective owners. This content is for informational purposes only and is not affiliated with or endorsed by these companies. Implementation examples are illustrative; please verify technical and legal requirements before applying them in your own systems.

#Salesforce #PlatformEvents #ChangeDataCapture #SalesforceIntegration #EventDrivenArchitecture #MuleSoft #EnterpriseIntegration #Middleware #APIIntegration #EventStreaming #RealTimeData #DataSynchronization #BusinessAutomation #DigitalTransformation #WorkflowAutomation #CloudArchitecture #Microservices #SystemIntegration #ScalableSystems