top of page
lp.jpeg

Blog

Tags:

Trigger Events in Salesforce; Receive Them in MuleSoft



We all know that MuleSoft is now part of Salesforce. It's been more than two years since Salesforce acquired it.


But even before the acquisition, those two have had a strong integration.



In my opinion, as a person who has been working in the integration space for more than 20 years, one of the most attractive things within their integration through the MuleSoft Salesforce connector, is the ability to subscribe to events that occur within Salesforce.


One of the challenges that has always been present when you are integrating an application is the ability to generate events that 3rd parties can subscribe to. This is a good element for an Event-Driven Architecture (EDA), and really a differentiator if you are building a connectivity/integration initiative.


Well, Salesforce offers a lot of alternatives to generate events. Not only within Salesforce boundaries, but also across them. And one key player here for that regard, is MuleSoft via its Salesforce Connector.


Salesforce offers:

  • Push Topic Event

  • Generic Event

  • CDC

  • Platform Event

  • etc.

Which are different alternatives to generate events within Salesforce, after a change has occurred in one of its objects or when you programmed that the event should occur (APEX, Workflow).


Some of them are more flexible than others in terms of the customization and data that the event can contain.


But something that they have in common, is that they can be used by the MuleSoft Salesforce Connector, and with that, trigger a MuleSoft flow. And now within a MuleSoft flow, you can pretty much do whatever you want with the data and send it to other systems, or publish the information through another event mechanism for 3rd parties.


Let's imagine you want to inform another system every time a create, update or delete for a Lead happens. But you do not want to be polling Salesforce every now and then to look up for new Leads. What you want is to be notified that the event happened and then manipulate the information and send it to others, or process them, or whatever you want to do with it.


In the last paragraph I said "you do not want to be polling," I mentioned it because that is a common practice, but a very bad one. Rather than doing that, you can subscribe for events and process them only when they happen and you are ready to receive them. That is a cleaner and more effective approach, and it can help you to understand the value of an Event-Driven Architecture.


MuleSoft is a very versatile platform. It offers an API platform, but also an API implementation and integration platform. Not only that, it can be used to expose asynchronous APIs, to serve as part of an EDA architecture.


In this post I am going to show you how we can create a MuleSoft Flow that can react to three different events generated by Salesforce:


1. On Create Event

2. On Modify Event

3. On Delete Event


We will use Lead as the entity in Salesforce. We are interested to know if a Lead was created, updated, or deleted.


But again, we want to react to the event. We are not going to be asking Salesforce if a Lead was created, updated or deleted. No! We are going to subscribe and react.



Creating the Mule Project


In order to do that, let's create a MuleSoft project that will look like this:



We have three different flows: one per event. After we receive the event, we simply send it to the logger.


In order to achieve this, we need two things:

  1. Create the MuleSoft project and use the Salesforce connector. In order to configure the Salesforce connector, you need a developer account (https://developer.salesforce.com/).

  2. Create a Lead in Salesforce and play with it: update it and delete it.


The steps are:


1) Create a MuleSoft Project:



2) Name it: “triggers01” or any name you would like to use.


3) Once the project is created, let's create a properties file that will include the Salesforce connectivity information.