The combination of Salesforce and MuleSoft Anypoint Platform is a match made in heaven. There are many rich ways to integrate to the Salesforce clouds and our Salesforce Connector provides a comprehensive way to connect with each. From an integration perspective, it is tempting to treat Salesforce as just another endpoint, but for best results, a deeper understanding of Salesforce can go a long way.
Getting the most from your Salesforce integration solution
While all organizations and applications are different, there are a few questions we recommend that you consider on an architectural level when designing your Salesforce integration solution.
1. Have an Org Strategy in mind
An “Org” is what we call a specific instance of Salesforce. In many organizations there are multiple Salesforce Orgs in use across different business units and many need connectivity between them. While technically this is achievable via various means, from a strategic perspective it is worth understanding what the long-term plan is for the consolidation or continued separation of the Salesforce Orgs themselves. We refer to this as an “Org Strategy.”
In most cases, a long period of reflection is not an option, however, taking time to think about the Org Strategy is worthwhile as it causes us to consider critical questions such as:
- What is our strategy for our Orgs? Is the current structure supporting or hindering our business? Is the integration effort masking a more fundamental issue?
- Are we solving an integration problem when there is a better business case for finding an integrated AppExchange solution on the Salesforce platform?
- Are we undertaking a significant integration project when greater business benefit would be realized by starting the process of consolidation of our Orgs?
2. Factor Governor Limits into your architecture
Governor Limits are the guardrails that Salesforce uses to make sure that all tenants are well behaved in our multi-tenant architecture. They provide boundaries for Salesforce applications in terms of resource consumption within an Org, such as the number of queries per transaction, long-running API callouts, and inbound API requests.
Since breaching Governor Limits often results in a failed business process, it is critical that the relevant Governor Limits are understood for a given integration so that scenarios are modelled to understand possible breach scenarios. Non-functional requirements are critical to exercising potential solutions against Governor Limits, so it is critical that the architectural methodology employed duly captures them.
There are a variety of coping strategies that Anypoint Platform can facilitate. Caching or replication of data outside of Salesforce, for example, may mitigate against Governor Limits being hit for heavy-traffic applications such as a mobile app. Use of throttling policies to protect the Org may be another approach.
In some cases, additional capacity is purchased to extend limits but this additional cost is a factor that will need to be considered for the overall solution.
3. Remember that Apex is not middleware
Apex is the Java-like programmatic environment to enable organizations to extend the capabilities of its Orgs with custom business logic where out-of-the-box configuration will not meet requirements. It is a powerful set of capabilities that amongst many other things allows organizations to create custom APIs within their Salesforce Orgs and call to third-party APIs for additional data. Because of this many developers are tempted to stretch Apex beyond its intended use and use it for coding middleware-like functions, rather than using a specialist integration and API platform like Anypoint Platform.
Apex is neither designed nor optimised for the complex processing that middleware applications typically require and is subject to Governor Limits defined with its true purpose in mind. You should reconsider your design if you’re using Apex rather than Anypoint Platform and/or other middleware to solve problems such as:
- Data translation between Salesforce and the proprietary formats of a third-party system.
- Routing or enrichment between different third-party endpoints.
- Complex orchestration of services across multiple systems.
- Providing message queuing capabilities between applications.
4. Understand when to move data to Salesforce
Another consideration when integrating with Salesforce is the movement (or otherwise) of data from the source application to the Salesforce Org. There are many business factors that influence this consideration ranging from regulatory to data currency. On the surface, Salesforce offers the option of creating records within the Org or accessing remote systems via OData, both of which you can accomplish using Anypoint Platform.
In addition, there are some further considerations to keep in mind.
- Data capacity within an Org is allocated based on the version and/or the number of licenses. You can purchase additional storage, but capacity planning and an archival strategy is strongly recommended. This is especially important if significant data is moved to Salesforce.
- If the use case involves large volumes of records in Salesforce (millions of records) then reference the Best Practices for Deployments with Large Data Volumes.
- If the use case is primarily to use external data within Salesforce for reporting and dashboards and volumes are significant, consider supplementary tools like Einstein Analytics. In addition to offering richer business analytics features, it has data movement capabilities designed to support analytics use cases and can integrate with “live” data in the Org.
- Accessing remote data via Salesforce Connect and OData can be a good option when data currency is important and the data is volatile. For example, inventory or the status of an order. While External Objects appear similar to Custom Objects, additional latency inherent in a remote connection means that their use can have user experience implications depending on your use case.
5. Know your configuration options
It is also worth remembering that Salesforce provides out-of-the-box options for integrating without the need for code. These are great options for simpler integration needs, but if they meet the integration requirements they may save significant time, cost, and effort.
Salesforce to Salesforce enables the sharing of records between two separate Orgs by copying records from one side to the other via a configured link. This is useful when working with a Partner who also uses Salesforce. Some field mapping is possible though no capability is made for complex transformation to mitigate significantly different data structures. As this approach makes a local copy of remote objects, this will consume data allocation within the receiving Org.
The Cross-Org Connector for Salesforce Connect has a similar effect in that data from another Org can be surfaced by accessing the data remotely rather than making a copy. This is similar to that of using OData. Note that this approach consumes API calls on the provider Org, so as described earlier Governor Limits may come into play depending on the volumes involved.
Putting it all together
MuleSoft’s Anypoint Platform and Salesforce are perfect companions for solving complex integrations needed to support rich customer and seller experiences. With the right architectural considerations, organizations maximize the value they can realize from the tools and create an integration approach that will scale with the ambition and expectation of the business.
