Integration Using Change Data Capture and Platform Events

Have you been avoiding an integration user story because you’ve been intimidated by an elaborate chart from Salesforce? Evade no more! A simple event-driven integration shouldn’t be difficult if done correctly. As a Salesforce org grows, it is natural to be asked to connect with another system.

Without further ado, let’s press the cog icon in Salesforce and head over to Setup → Platform Tools → Integrations. It’s time to get hands-on with change data capture (CDC) and platform events.

Change Data Capture

A change data capture (CDC) is used for a simple, one-way, outbound, data broadcast from Salesforce. For example, say that an external system wants to receive a broadcast every time a Salesforce account record is created, updated, deleted, or un-deleted.

Setting that up takes just four clicks:

That is literally everything you need to do when setting up CDC. Easy, right?

Using Workbench, you can test your Salesforce broadcasts for external systems. Start by logging in to Workbench:

Be cautious that you log into Workbench using your free Salesforce developer org, and not via a customer’s org:

Accept the requested permissions, then go to Queries → Streaming Push Topics → Generic Subscriptions radio button. Then type /data/AccountChangeEvent in Subscriptions, and press the Subscribe button.

Note: For standard objects, it’s /data/<StandardObject>ChangeEvent without the < >.

For custom objects, it’s /data/<CustomObject>__ChangeEvent without any < > or __c.

Here is an account record broadcast. You can see that I changed its rating to Cold in Salesforce:

Here is the broadcast upon deleting the record:

And lastly, here is the broadcast upon un-deleting it from the recycle bin:

Furthermore, if you try to subscribe to an object that hasn’t been “CDC-enabled” from Salesforce Setup (or if you try to subscribe to a typo), you will get an error.

External systems can use this broadcast as per their needs, creating a simple, one-way, fire-and-forget, outbound integration from Salesforce.

If you show the subscription value and some sample broadcasts to your external system’s technical lead, they should be able to take it from there.

Platform Events

Now, let’s get hands-on with platform events. A platform event is used for integrations that need a bit of logic, and usually work together with flows.

Platform events are like custom objects. The difference is that they store broadcasts. They don’t have tabs and their developer name ends with __e. Platform events can also be used for two-way integrations.

Let’s take a rudimentary example. An external system wants to receive the account name and its 18-character ID every time a Salesforce account record is created or edited, and it would also like to send back an account number to be added to the Salesforce account record. We would also need to design it to not cause recursion due to the last action.

First, be sure to disable the Account CDC from our first example. Next, let’s go to Setup → Platform Tools → Integrations → Platform Events → New Platform Event.

Create the platform event object. In our rudimentary example, we will use the same platform event for both outbound and inbound integration:

Tip: Don’t name it the same as a standard or custom object, such as “Account” or “Bank”, thinking that you can distinguish platform events because their API name ends with __e . In many places in Setup, you will see only label names, such as account and account, and then you’ll wonder which one is the object and which one is the platform event.

Next, create the required fields. In our rudimentary example, we will create an account name, account number, and a Salesforce account record ID.

After that, create a record-triggered flow. Remember that we should not broadcast when an account record is modified by an integration user, as that will lead to recursion. So, in our rudimentary solution, we designed our flow to broadcast only when the username does not contain the word “integration”.

Next, create a platform-event-triggered flow for the two-way integration. The external system will use this to send us the account number.

Finally, test in Workbench. The subscription will be /event/Account_Platform_Event__e.

Edit any account record in Salesforce and the fields of the platform event should show up:

Try test-sending an account number to Salesforce via the integration user as well. For a quick test, you can temporarily append “integration” to your own username, but remember to change it back later.

Verify that there was no recursion:

Lastly, check that the account number showed up in Salesforce.

If you show the subscription value, sample broadcasts, and sample POST requests to your external system’s technical lead, they should be able to take it from there.

Final Thoughts

That was a full run-through of CDC and platform events. Hopefully you now understand how useful they can be for data broadcasts and event-driven integration. To recap:

1. Consider CDC for simple, outbound, one-way, fire-and-forget data broadcasts.
2. Consider platform events with flows when you need a bit of logic or data processing.
3. Use platform events and platform-event-triggered flows for inbound integrations.
4. Consider configuring and switching on state and country picklists to prevent mismatches during data integration.
5. Only let external systems insert platform event records; do not let external systems use the REST API to directly insert or modify Salesforce records. Then it becomes a point-to-point integration, losing the benefit of being loosely-coupled and event-driven.
6. Lastly, don’t forget to design in a way that prevents unwanted recursion.

Resources

• Salesforce Platform Events: Explained
• Ultimate Introduction to Salesforce Integration 
• Rethinking Your Architecture With Platform Events 
• Which Streaming Event Do I Use? 
• Salesforce Change Data Capture (CDC) Events and its test 
• CDC
• Streaming API – Change Data Capture – Salesforce Stack Exchange
• Is Salesforce CDC Based on Platform Events – Salesforce Stack Exchange
• Remote Process Invocation — Fire and Forget | Integration Patterns and Practices | Salesforce Developers
• Event-Driven Architecture | Salesforce Architects 
• Platform Event – Will Change Data Capture Eventually Replace PushTopics/Streaming API? – Salesforce Stack Exchange
• Publish Event Messages with Salesforce APIs 
• How Many Flows Should You Have Per Object?