A powerful integration platform empowers everyone in your company from IT to line of business leaders, small businesses to enterprises, integration to API management — to unlock data and go digital faster.

Salesforce integration use cases are growing every day. MuleSoft helps you unleash the power of Salesforce’s Customer 360 by unlocking, unifying, and securing data from any system — whether it’s in Salesforce or any other system — to deliver truly connected experiences.

The core project team generally consists of a MuleSoft and Salesforce team, with architects and developers from both. The MuleSoft team needs to be comfortable with Salesforce workbench and other basics, such as orgs, objects, properties, object parent-child relationship. The Salesforce team should have a basic understanding of MuleSoft, API-led connectivity, API reuse, and Salesforce integration patterns.

Want to ensure seamless integration between Salesforce and MuleSoft? Here are nine best practices for your business:

1. Understand end-to-end business requirements
2. Segregate responsibilities
3. Finalize security settings between Salesforce and MuleSoft
4. Map Salesforce orgs to the MuleSoft environment
5. Create a property mapping document
6. Define transformation logic responsibilities
7. Determine where business logic lives
8. Log key events
9. Facilitate integration performance testing

Plan discovery and requirement gathering sessions with the customer/business stakeholders, as well as the Salesforce and MuleSoft teams. In these sessions, work to understand the problem you’re trying to solve, business use cases, and integration use cases, expected SLAs, and agree on guiding principles of integration patterns.

You should define the items listed below during the planning and architect phase of the project, before the effort estimation work starts.

It is critical to understand which data and integration requirements are handled by Salesforce and which are handled by MuleSoft. Clearly define how data will flow and where data transformation will take place.

For example, MuleSoft will fetch data from a third-party system, transform x, y, z data elements, convert the data to JSON, and insert it into Salesforce objects. Meanwhile, Salesforce will automate further data processing on the data saved by MuleSoft.

There are multiple ways to integrate Salesforce with MuleSoft, such as the Salesforce adapter provided by MuleSoft, or calling MuleSoft APIs within Salesforce, or platform events. Regardless of the method, be sure to choose the right security level per your org’s policy.

The below diagram shows an example of the security method needed for MuleSoft’s Salesforce connector. OAuth 2.0 provides better security/options security compared to basic authentication.

While calling MuleSoft API from Salesforce code, choose the highest possible security level as well. MuleSoft provides a variety of security options. The security aspects should be reviewed and approved by both the teams and the customer/infosec team. Rule of thumb? Choose the highest security level possible.

Create a diagram that illustrates which Mule environments connect to which Salesforce orgs and other external systems. This clarifies data flow and exposes potential issues.

The below diagram illustrates a sample diagram — highlighting a problem where the customer had only three MuleSoft environments, but Salesforce external systems have four. Such a diagram will help map out a strategy for how the systems will interact with each other.

Creating a mapping document that lists properties from external systems and Salesforce is one of the most critical steps. As shown in the diagram below, this mapping document defines MuleSoft scope, orchestrations, data/DataWeave transformations. This should be co-owned by both teams and approved by key stakeholders/customers. That will ensure the completeness and quality of the data.

Define which transformation logic will be handled by MuleSoft and which will be handled by Salesforce. Decide whether the MuleSoft APIs will be reused by other systems. If they are, MuleSoft should handle the transformations instead of Salesforce. That way, all clients will receive a consistently transformed response, and it will be easier to replace external systems later on.

Given a choice between MuleSoft and Salesforce, any business logic should ideally reside in Salesforce. Placing it within MuleSoft might change the code/deployment if the business logic changes. If it is set in Salesforce, it can be managed in Salesforce Admin setup screens. Salesforce developers can also use its custom metadata to provide configurable interfaces. Configurable interfaces provide business users flexibility to modify the business logic without code changes.

Example of metadata setup in Salesforce: API-related (endpoints, URLs, versions, credentials, etc),  timeouts, headers, content-type etc. They should be properly configured/externalized in Salesforce so they can be changed easily.

Apart from regular MuleSoft logging (which is mainly for the technical team), it is beneficial to log key events in Salesforce. This is not the debug logs, but the key events/milestones that happen during API/batch flows. A common logging utility can be used that gets called from within the code to note key events. This includes receiving a request, calling external systems, saving the data in Salesforce, any error that happened in the process, and so on.

This helps Salesforce admins view the status, understand what actions were performed by MuleSoft API, see any issues that occurred, and in which stage of the flow they occured. Once recorded these events logs will be available in Salesforce under that customer’s account which can be viewed/monitored by non-technical resources.

Like any project or unit, integration performance testing is important. Check the response time to make sure SLA is met. Test with real data, also the batch process to test MuleSoft/servers performances. Automated testing, e.g. selenium testing, can be helpful.