An event-driven approach to Salesforce integration

A number of the materials (posts, tutorials, etc.) available out there present an approach to integration between MuleSoft and Salesforce on the basis that MuleSoft is always proactively responsible for starting communication, injecting or pulling CRM data based on a schedule or otherwise. 

This post aims to present a different approach to integration between these two platforms, where MuleSoft works in a more reactive way, triggered by notifications (events) sent by Salesforce representing new or modified data, rather than as scheduled or incremental requests. In this post, I will show you the different patterns to implement this approach.

Complete notification: event and object instance

In this pattern, Salesforce calls an API exposed by MuleSoft on a fire-and-forget mode containing a full-blown notification with headers indicating what is the object, if it is a new or has been modified. Plus the current state of the object instance at the time it has been created or modified. 

Example of the HTTP request body (JSON):

This pattern does not require a round-trip from MuleSoft back to Salesforce to query the current state of the object instance.

Simple notification: Event-only

In this pattern, Salesforce calls a RESTful API exposed by MuleSoft on a fire-and-forget mode containing a lean, simpler notification indicating what the object is. If it is new or has been modified and the object instance ID. 

Example of the HTTP request body (JSON):

Unlike the previous one, this pattern requires a round-trip from MuleSoft back to query the current state of the object instance (by ID).

In practice

At this stage, most likely, the implementation aspect of MuleSoft does not require further explanation and details, but to follow this article, Salesforce absolutely does. 

With Salesforce, developers can leverage Apex, a Java-like programming language that allows execution of flow and transaction control statements on Salesforce servers and calls to the API that can be initiated by Web service requests and from triggers on objects. 

Note: In order to allow creation and execution of such classes and triggers as well as to allow connectivity to external systems, some specific configurations have to be done in Salesforce. More details can be found on the Salesforce Developers website.

Salesforce Apex Classes

Let’s start by creating two Apex classes, one for product inserted and another one for product modified. The Product inserted class will fire a complete notification to MuleSoft API while product modified class will fire a simple notification. Apex classes can be created from Salesforce’s Developer Console.

Product inserted

Product modified

Salesforce Apex triggers

After having implementing the Apex classes, it’s time to implement the corresponding Apex triggers. That can also be done from Salesforce’s Developer Console.

Product inserted trigger

MuleSoft implementation

Now it’s time to completely switch context (and platform) to MuleSoft’s Anypoint Platform to start developing the MuleSoft side of the solution. For simplicity of this example, rather than fully specifying an API and all its details, let’s create a simple Mule application in Design Center with five flows, where each of them addresses one piece of the puzzle.

System API flows

Process API flows

And there you go! A complete event-driven solution that implements two patterns for integration between Salesforce and MuleSoft by using best of breed capabilities on both platforms.

Download our ebook, Unleash the full power of Salesforce Customer 360 with APIs, for more information on how to integrate Salesforce and MuleSoft.

We'd love to hear your opinion on this post

4 Responses to “An event-driven approach to Salesforce integration”

  1. Why not use Platform Events baked into Salesforce?

    • I completely agree. Using SalesForce push topics allow for event driven notification without apex code that has to be validated with every SalesForce Release. Also, push topics allow for query based output to the subscriber if you are trying to minimize round trip traffic.

  2. This is really great. Been looking for this kind of event based triggering support for quite sometime. Much cleaner approach instead of constant polling

  3. The “System API” should be an experience api I would suggest. Salesforce is the client application – it should be talking to an experience api if it is the one creating the notification.