ProstDev ProstDev
Tutorials May 18, 2021 · 8 min read

Trigger Events in Salesforce; Receive Them in MuleSoft

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: On Create Event, On Modify Event, and 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.

By Rolando Carrasco
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:

Mule project with three flows, each a Salesforce trigger (New, Modified, Deleted Object) into a Logger.

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:

  • 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/).
  • Create a Lead in Salesforce and play with it: update it and delete it.

The steps are:

  1. Create a MuleSoft Project:

New Mule Project dialog with Mule Server 4.3.0 EE runtime selected and an empty project name.

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

  2. Once the project is created, let’s create a properties file that will include the Salesforce connectivity information.

salesforce.yaml under src/main/resources holding sfdc username, password and token properties.

The token is generated via the developer.salesforce.com portal, as well as the user and password.

  1. The properties (yaml) file needs to be located in the folder that is indicated in the previous image (src/main/resources).

  2. Now let’s create two entries in our Global Elements tab:

Global Configuration Elements tab with Configuration properties and Salesforce_Config entries.

  1. For the Salesforce Configuration, you should input this:

Salesforce Config properties with Basic Authentication username, password and security token from the YAML.

As you can see we have configured username, password and token. We’re getting the values from the properties file. It is a good practice to use this type of configuration. Once you typed it, click on Test Connection:

Salesforce Config showing a "Test connection successful" confirmation dialog.

  1. Now it’s time to create the flow. As we’ve previously mentioned, we will react to events. Therefore, we are not going to drag and drop HTTP listeners. We are going to drag and drop a Salesforce Connector capability.

  2. Let’s start with the On Create Event. But before that, make sure you have added the Salesforce Connector into your Mule Palette. Like this:

Mule Palette with the Salesforce connector module added alongside Core and HTTP.

  1. Now, let’s add the On New Object. Please locate it, and drag and drop it in the Canvas:

Salesforce palette operations list with the On New Object trigger highlighted.

  1. Now you should have this:

A single flow with the On New Object Salesforce trigger dropped onto the canvas.

  1. Repeat the same formula for these two events:

Salesforce palette with the On Modified Object and On New Object triggers highlighted.

  1. Drag and drop them into the canvas. And now you should have this:

Three flows each starting with a Salesforce trigger: On New, On Modified, and On Deleted Object.

  1. Now let’s add a logger activity into the On New Object flow, and configure it like this:

Logger added after the On New Object trigger, configured with the payload as its message.

  1. Repeat the same formula for the other two flows. Now you will have this:

All three flows now complete: each Salesforce trigger connected to its own Logger.

  1. Now let’s configure the three events. Let’s start with the On New Object event. Double click the activity and configure it like this:

On New Object config: Lead object type, Fixed Frequency scheduling, every 5 seconds.

As you can see we’ve configured different elements:

  • Display Name: It can be whatever you want.
  • Connector Configuration: It should be already selected, since you created it in previous steps.
  • Object Type: This is the entity to which you want to be informed if a new one is created, modified or deleted. In this case we are going to use Lead.
  • Scheduling Strategy: It is the frequency to which we are going to get the event messages.
  • Since: This is a key element because events in Salesforce are independent of the Connector. So, if you are already publishing events when you start the MuleSoft app, it will retrieve the messages that were created before. But if you choose a date, then only the events created after that date will be retrieved. So be careful with this field.
  • Frequency: It is related to the Scheduling Strategy. In our case it will be every five seconds.
  • Time Unit: In this case, seconds.
  1. Now let’s do the same thing for the On Modify and On Delete, like this:

On Modified Object config with object type Prospecto (Lead) and Fixed Frequency scheduling.

and

On Deleted Object config with object type Prospecto (Lead) and Fixed Frequency scheduling.

  1. Now we are ready to test this. Right click your project and Run the project. The project should be in the DEPLOYED status. Like this:

Mule console showing the triggers01 application in DEPLOYED status on Mule Server 4.3.0 EE.

Now we are ready to create some Leads in Salesforce, and see how our MuleSoft application reacts to them.

Triggering the Mule Flows

Go to https://salesforce.com and log in with your credentials. Look for the Leads tab:

Salesforce Lightning Sales home in Spanish with the Prospectos (Leads) tab in the navigation.

(Here you see it in Spanish, because my defaults are in Spanish. But in English it is “Lead”).

Let’s create a new Lead:

New Lead form in Salesforce filled in for Jose Perez at company SPS, with email perez@me.com.

Just fill the necessary elements, and click create the Lead. After that, get back to Anypoint Studio, and see what was written in the log:

Two Mule log lines from triggers01Flow and triggers01Flow1 logged after creating the Lead.

You have two new lines, and if you scroll to the right, you will see the details of the Lead you’ve created:

Logged Lead details scrolled right, showing FirstName=Jose and Title=CTO for the new record.

Why two?

Every time you create an object, it generates two events: one for creation, and one for modification.

Now let’s test the modification event. Let’s edit the Lead changing the contact email:

Lead detail page for Mr. Jose Perez with the email field perez@me.com highlighted before editing.

Let’s edit the email address:

Editing the Lead's email field to jose_perez@me.com in the Salesforce inline editor.

After you’ve edited, you will see a 3rd line in your log, where you can see the updated email address:

Mule log of the modify event showing the updated Email=jose_perez@me.com value.

Pretty simple, right?

With this, you can change the perspective on how you can integrate Salesforce with other applications. The connector is very powerful and the events layer in Salesforce as well. And they are integrated, so you can do the math and conclude that this is a great ability within MuleSoft.

FAQs

Frequently asked questions about this post.

  • Which Salesforce events can a MuleSoft flow react to in this tutorial?

    The post builds three flows, one per event: On Create Event (the On New Object trigger), On Modify Event (the On Modified Object trigger), and On Delete Event (the On Deleted Object trigger), all using Lead as the Salesforce entity.

  • Why subscribe to Salesforce events instead of polling for changes?

    The post calls polling a common but very bad practice; instead of repeatedly asking Salesforce whether a Lead was created, updated, or deleted, you subscribe and react to events only when they happen and you are ready to receive them, which is a cleaner and more effective Event-Driven Architecture approach.

  • How do I configure the Salesforce connector in the Mule project?

    You first need a Salesforce developer account from https://developer.salesforce.com/ to generate the username, password, and security token, then store those in a salesforce.yaml properties file under src/main/resources, create a Configuration properties and a Salesforce_Config entry in the Global Elements tab, set Basic Authentication to read the username, password, and token from the YAML, and click Test Connection to confirm it succeeds.

  • Why do two log lines appear when I create a single Lead?

    Because every time you create an object it generates two events, one for creation and one for modification, so creating one Lead fires both the On New Object and On Modified Object flows.

  • What does the Since field do on the trigger configuration?

    Events in Salesforce are independent of the connector, so if events were already published before you start the MuleSoft app it will retrieve those earlier messages, but if you choose a date in the Since field then only events created after that date are retrieved, which is why the post warns to be careful with this field.

Search

Loading search…