What Is Change Data Capture?

Change Data Capture is a Lightning Platform streaming solution that lets you effectively connect your Salesforce data to other platforms. You may synchronize matching records in an external data store and get real-time updates to Salesforce records using Change Data Capture. Events for creation, updating, deleting, and undeleting Salesforce records are published by Change Data Capture.

To update data in an external system, use Change Data Capture rather than polling an API or doing recurring exports. Using Change Data Capture event alerts to record changes guarantees that your external data is up-to-date and current.

New and updated data is continuously synchronized with the external system through a process known as change data capture. Stated differently, it makes the Salesforce data deltas—whether for new or modified records—public. An integration app is necessary for Change Data Capture in order to receive events and update the external system.

Key Benefits:

  • Real-time data synchronization: Avoid manual polling and maintain external systems up to date.
  • Dependable event delivery: Subscribers may catch up if they miss events since events are saved for 72 hours.
  • Integrations are made simpler: Complex API polling is not as necessary.

When to Use Change Data Capture

Use change events to:

  • Get alerts when anything happens in Salesforce records, including when they are created, updated, deleted, or undeleted.
  • Keep track of most field changes for every record.
  • Get details about the modification, including where it came from, in the event header so you can disregard changes made by your client.
  • When a transaction has many operations, use transaction boundaries to update the data.
  • Get an event schema that is versioned.
  • Get scalable access to mass changes.
  • Gain three days of access to events that have been retained.

What Are Streaming Events and Why Use Them?

Instant notification messages are known as streaming events, and they are sent from one system (the publisher) to another (the subscriber). Change Data Capture uses the publisher/subscriber approach to notify subscribers each time Salesforce data changes. Clients can subscribe to the event bus, which receives notification messages, either utilizing Apex triggers or the Pub/Sub API. In addition to providing real-time data and increasing scalability, event-driven systems facilitate communication between dispersed corporate systems. Connecting systems using an event-driven architecture is more effective than polling data using REST or SOAP APIs.

The freshness of the data is dependent on the poll frequency when utilizing APIs to poll the server for data changes. Clients may also make too many calls, which slows down servers.

Enabling Change Data Capture

To enable the objects for receiving change notification follow below step.

  • Go to Setup: In the Quick Find box, type “Change Data Capture” into it.
  • Choose Object: Decide which objects (such as Accounts) you wish to record changes for.

capture 1

  • Adding to Selected Organizations: Salesforce will begin posting change events as soon as you save your modifications.

Permissions for Receiving Change Events

All of a Salesforce object’s records get change events via Change Data Capture, which disregards sharing settings. The subscribed user has to have one or more permissions, depending on the entities linked to the change events, in order to receive change events on a channel.

Field-Level Security

The field-level security settings of your organization are respected by Change Data Capture. Only the fields that a subscribing user is permitted to access are included in delivered events.

Asynchronous Apex Triggers for Change Events

Apex triggers may be used on the Lightning Platform to subscribe to change events. Although they differ in a few ways, Apex triggers for change events are comparable to those for Salesforce objects. You define a change event trigger on the change event that corresponds to the Salesforce object, just like you would with an Apex trigger for Salesforce objects. Insert triggers are only supported after that.

The AccountChangeEvent object, which represents the change event associated with Account, is demonstrated below.

capture 2

The change event trigger fires when one or a batch of change events is received. Unlike object triggers, change event triggers run asynchronously after the database transaction is completed.

These traits are present in change event triggers.

  • The Automated Process entity oversees their operation. Consequently, the Automated Process entity generates debug logs for the trigger, and Automated Process is referenced in system variables like CreatedById and OwnerId.
  • The restrictions of the Apex synchronous governor apply to them.
  • 2,000 event messages (the total number of items in Trigger.New) is the maximum batch size they can have.

Important Considerations for Asynchronous Apex Triggers

When working with change event triggers, there are a few critical points to keep in mind:

  • Here is list of supported object
  • Supported Object Naming:
  1. For standard objects, the change event name follows the pattern: StandardObjectNameChangeEvent (e.g., AccountChangeEvent).
  2. For custom objects, the change event name follows the pattern: CustomObjectName__ChangeEvent (e.g., Employee__ChangeEvent).
  • Asynchronous Trigger Execution:
  1. Asynchronous Apex triggers run after a database transaction is completed.
  2. Available only for the after insert event.
  • Handling Complex Logic:
  1. Asynchronous triggers allow you to move complex computations or heavy logic out of the main transaction, improving performance and avoiding governor limits.

Example Use Case: Salesforce & External Billing System

Let’s say your billing system isn’t Salesforce. Every time an account is updated, you want to update it as well. You may log the data, capture the change event, and use platform events or outgoing messages to notify the billing system without halting the initial transaction by utilizing CDC in conjunction with an asynchronous Apex trigger.

Best Practices

  • Filter events: Use ChangeEventHeader to filter unwanted events.
  • Batch processing: Handle events in batches to avoid hitting limits.
  • Error handling: Implement robust error handling and retries.
  • Optimize logic: Offload heavy processing to asynchronous jobs for better scalability.

Conclusion:

One of the most useful features for creating scalable, real-time Salesforce interfaces is Change Data Capture. CDC makes it easy and dependable whether you want to use Apex triggers to manage changes within Salesforce or sync data with external apps.

Stay curious, keep experimenting, and we’ll see you in the next blogs. Also, stay tuned with The Pinq Clouds available on AppExchange for insightful blogs and updates. Happy coding!