​Three Best Practices for Salesforce Application Integration

Salesforce offers many options for integration with other applications — CRM, ERP, HCM, BI and MDM. Application leaders supporting Salesforce can optimize their integration strategy with our best practices for Salesforce integration.

Key considerations

• Technology leaders report that they lack guidelines on integration technologies and integration design best practices, which impacts the relevance of the Salesforce implementation to business processes.

• Organisations are challenged to ensure that their organization matches the proper integration Salesforce technical design pattern with the correct Salesforce integration type.

• Business requirements for real-time updates often collide with the technical capabilities of the Salesforce API.

Salesforce integration challenges

Organisations looking at best practices for Salesforce integration, they are commonly referring to how to integrate Salesforce with other CRM applications, or with their ERP, HCM, MDM and homegrown systems. These requests are driven by three objectives:

• Optimize the efficiency of their customer-facing processes.

• Build a 360-degree view of all customer data, particularly providing a historical view of all interactions and transactions.

• Deliver innovative new processes.

These observations are backed by recent survey data. According to a Business Application Integration Survey, 63% of respondents with CRM implementations indicated that process efficiency was one of their top three goals for their application integrations. The same percentage of respondents aimed at improved insight. And 52% aimed at delivering more innovation to their organizations.

This same survey revealed three main challenges to building and maintaining a comprehensive Salesforce integration program, one that spans all CRM processes and integration with ERP and master data management systems.

​

Top Three Challenges to Building a Salesforce Integration Program

Figure 1. Top Three Challenges to Building a Salesforce Integration Program

Because of these challenges, we find that Salesforce clients hesitate to build a comprehensive application integration strategy. While these are important considerations, application leaders supporting Salesforce deployments have to be involved in the integration program.

To that end, this research note supports three considerations in a Salesforce integration program:

• How Salesforce integration requirements fit with their overall business application integration strategy

• Identifying the correct Salesforce integration types for their business use cases

• Managing the scope and frequency of data integrations between Salesforce and other systems

This research notes addresses all of those considerations for integration with the core Salesforce products, including Salesforce Sales Cloud, Service Cloud, Community Cloud and the Salesforce platform. This note does not address considerations for noncore Salesforce products that were not developed by Salesforce themselves, such as Marketing Cloud.

Also, note that integration types and integration timing are not the sole considerations in a Salesforce integration program. It is outside the scope of this document to outline all of the considerations. Salesforce details all of the considerations and outlines common design patterns in this free Integration Patterns and Practices resource from the Salesforce developer website.

Work With Your Internal Integration Architects to Build an Overarching Salesforce Application Integration Strategy

Integration work is both resource-intensive and capital intensive. In the same research survey noted earlier, respondents indicated that in CRM projects, on average, integration accounts for 21% of the total project costs. And it can be as high as 45% of the total costs.

Being able to address your Salesforce integration challenges in a strategic, rather than opportunistic, fashion that provides clear guidelines is the key for success.

In the 2019 Business Application Survey, 37% of the respondents indicated “lack of an integration strategy” as one of the top three integration challenges for their CRM projects. And 41% mentioned “selecting the right integration architecture” as another challenge.

However, the Salesforce integration strategy is a component of your organization’s broader business application integration strategy, which should also encompass other domains such as ERP, HCM, SCM and cloud office. Plan to make the Salesforce integration approach a contextualization of your overarching business application integration strategy.

If your organization hasn’t yet designed such an overarching vision, you can use the process to define your Salesforce integration approach as the template for your broader initiative aimed at designing business application integration strategy.

Given the scope of those costs and implementation strategy challenges, do not let Salesforce integration work be an afterthought. Utilize better governance practices to better protect the investment. We believe that application architects owning Salesforce implementations must define an integration strategy, because they have to guard against two integration governance issues:

1. Allowing integrators and contractors to build uncoordinated and unmanaged point-to-point integrations. Although some of this is inevitable, it should be limited to minimize costs, enforce centralized integration monitoring and management and effectively manage the life cycle of the Salesforce integration processes.

2. Unnecessarily duplicating costs and efforts by not using integration tools, design patterns and skills already in place in the organization.

To address these cautions, application leaders need to lead the governance strategy and tactics.

Start by forming a Salesforce integration strategy team. It should include architects from your Salesforce application teams and integration/API architects from your organizations integration strategy enablement team (ISET) and API platform team.

The first group should be well-versed in the API-based integration methods supported by Salesforce. The second group should be well-versed in your company’s integration and API strategy. Collectively, their experience and input are crucial for:

• Validating the decisions made for each dimension of the strategy.

• Assessing the suitability of any technology proposed or already deployed that will connect Salesforce with other applications.

• Determine how to fill technical and skills gaps in terms of Salesforce integration requirements not supported by your company’s integration and API strategy.

• Determine the costs associated with implementing the strategy in terms of skills, technologies and efforts.

The Salesforce integration team must address five correlated dimensions of the strategy: business drivers, functional requirements, nonfunctional requirements, governance skills and your architecture and technology.

As the team builds the integration strategy for Salesforce, ensure that they follow these guidelines:

#1: Resist the urge to only focus on integration frameworks, platforms and prepackaged integrations.

While it may be tempting for architects to start with technology considerations, it is the wrong approach. All five dimensions are equally important in building a durable Salesforce integration strategy.

#2: Match the Salesforce supported integration methods with your business drivers.

This is more than just a concept that is used to ensure that the team is “in line with the business.” Business drivers can help you take decisions throughout the entire spectrum of the strategy dimensions, because they closely link to the functional requirements and to the governance and delivery models.

#3: Select technologies and Salesforce design patterns at the end of the process, not earlier.

The design patterns and integration technologies only exist to satisfy the business drivers. You should select the integration technology toolset only when you have analyzed and fully rationalized all the other dimensions of your overarching business application integration strategy. And it is not always necessary to complete a full integration vendor evaluation. It is a best practice to employ the integration tools already deployed with your organization.

Of these three guidelines, the second is the most important. All integration strategies have to be aligned with business objectives and the processes that underpin those objectives.

Main Outcomes and Suggestions:

1. According to integration vendors that have been surveyed, the average Salesforce integration effort includes an estimated 20 to 30 integrations. Salesforce implementations of more than 100 integrations are also common.

2. According to the same integration vendors, the average project consisting of 20 to 30 integrations will take an estimated two to three months to complete.

3. The typical integration process takes an estimated eight to 10 days to design, test and deploy. The actual development effort can be as short as four hours and as long as three or four days, depending on the process complexity.

Base Your Salesforce Integration Design on the Pros and Cons of Each Salesforce Integration Type

Knowing what pattern of integration to use for a given use case is the most common challenge with Salesforce integration that we encounter. Accordingly, all Salesforce integration programs must be aligned with one of three integration patterns: data integration, process integration and virtual integration.

Table 1 below describes the three design pattern categories.

Table 1: Types of Salesforce Integration

Data consistency integration is the most commonly implemented type because it is the most straightforward method to meet integration requirements. Examples include real-time updates to customers’ ship-to addresses, order status or bulk updates to inventory on-hand levels. This is also the most common method for maintaining master data management (MDM) integrations.

Multistep process integration is a design pattern that we term “multistep process” integration. Examples include calculating taxes and volume discounts on a complex, multiregion product order or managing a multiproduct consumer insurance claim. This is the most complex design pattern to implement and maintain. It requires design, testing and exception handling processes.

Composite integration is applicable for situations where end users have to access many different systems of record to complete process steps, as is common in customer service call centers. It is used to merge the functionality of two independent applications without building complex data integrations that duplicate data storage in multiple systems, such as real-time look-ups into customer billing records. In this design method, the non-Salesforce applications are displayed within Visualforce iframes, or replicated within Lightning Components that mimic the functionality of the source applications.

We also note that in a large Salesforce deployment, there is not one single integration approach. If the deployment features multiple, different CRM processes across customer service, marketing, sales and digital commerce, then it is most appropriate to employ all three integration types.

The integration types do not exist in a vacuum. They are mostly relevant in the context of meeting specific business process needs. We find that these integration types support a number of business-critical use cases within Salesforce products, as depicted in Table 2 below.

Table 2: Salesforce Product Integrations by Use Case and Integration Type

Integration patterns within Salesforce implementations vary greatly across industries and use cases. Included here are two examples we gathered from two different industries.

An international company employs dozens of process and data integrations between Salesforce and SAP for MDM maintenance, using a data consistency design pattern. Users initiate new account requests in Salesforce, invoking a process to SAP for account set-up and verification. Account updates move from only SAP to Salesforce via a custom integration process. Address validations are performed via real-time multistep process integration with Dun and Bradstreet. Their long-term plans include unidirectional integration of Salesforce business contacts with a customer master data warehouse.

A high-tech company has dozens of data consistency and multistep process Salesforce integrations, linking Salesforce with more than 24 external systems for customer service, marketing, MDM and quote generation. In the long-term, the company plans to consolidate down to 11 external systems that will be supported by a combination of IaaS-based integrations as well as tactical first-party application-to-application integrations with Salesforce.

Based on information collected from Salesforce customers, system integrators and salesforce implementation experts, we make the following recommendations based on observations, for your integration design program.

Main Outcomes and Suggestions:

1. There is no single best implementation pattern for Salesforce. Implementations that span multiple CRM processes will require many different integration types. Business requirements should dictate which types of integration will be deployed.

2. Multistep process integrations are appropriate for most B2C sales, digital commerce, customer service and marketing processes, and for some complex B2B processes, such as quote generation and order management.

3. Virtual integrations are appropriate for B2B processes in situations where users must access business-critical system of record.

4. Only store duplicative data in Salesforce that is necessary for better process execution. Salesforce uses a rough estimate that states if 80% or more of the process is managed and completed within Salesforce, then the data should be physically stored in Salesforce.

5. Composite integrations are appropriate for large-scale B2C processes, particularly if your organization manages a large volume of transactions in systems external to Salesforce, as is common in verticals such as telecommunications, financial services, utilities and governmental services. We see growing use of the data integration hub pattern to support processes with low latency, high throughput and 24/7 operations.

6. If you need to quickly connect third-party application to Salesforce data integrations and have no plans to employ iPaaS tools in your implementations, use the third-party application vendor’s own API-based connectors.

7. Employ third-party application API-based connectors when you want to control the scope of integrations or to reduce the number of custom integrations that you must maintain with an iPaaS or iBPMS system. But note that these integrations require the same level of governance oversight that is appropriate for multistep and composite integrations.

8. As a matter of good integration governance, minimize the number of custom-built point-to-point data integrations.

9. Salesforce’s API does not have data transformation services, as is commonly required in ETL integration projects. This means that you will have to deploy an integration middleware solution — like an iPaaS solution, to handle any required data transformations.

10. Salesforce Canvas or Salesforce Lightning Connector can be used for virtual integrations.

Optimize Your Salesforce Integration by Implementing the Best Practices for Sequencing and Timing of API Calls

Integration sequencing and timing is the second most important component of Salesforce integration patterns. The Salesforce API also supports two different forms of integration timing methods — synchronous and asynchronous.

1. Synchronous is a blocking, near real-time type of integration, where the result of a process call to a remote system is returned immediately to the system that initiated the request. The process step that requests the data from the external system does not advance until the sending system returns a response.

2. Asynchronous is a nonblocking, queue-based type of integration. The calling system sends data to one or multiple external systems and continues without waiting for a response.

Timing is an essential consideration because it is the single largest point of failure in Salesforce integrations. Some organizations implement synchronous integrations, in the interest of providing highly responsive real-time CRM applications. Over time, those integrations fail because they were developed without regard to impact on the API governor limits imposed by Salesforce, or without regard to the resource costs of maintaining them.

Effective timing design also relies on using the correct Salesforce API type. Salesforce offers the following types of APIs for synchronous and asynchronous integration in Table 4 below.

Table 4: Salesforce API Type for Synchronous and Asynchronous Integrations

The Bulk API is often misunderstood. It is based on REST principles and is optimized for loading or deleting large sets of data. It can be invoked to manage CRUD functions asynchronously by submitting batches of data. Salesforce processes batches in the background.

Application leaders should note that the Bulk API is generally underused in Salesforce implementations and that the REST API is overused. Application leaders should not ignore the possibility of using the Bulk API in lieu of the REST API. Specifically, it is possible to apply near-real time data updates via the Bulk API. For example, the business requirements may specify that B2B credit checks run instantaneously. Requirements of this type should be validated for actual business need and relevance as near real time updates could be sufficient to meet the business requirements.

Application leaders will often find that it is not necessary to meet this with serial, synchronous REST API calls. It is common to use the Bulk API to return several results to end-users via the batch process within the Bulk API.

The REST and SOAP API calls are subject to governor limits by Salesforce. See Salesforce’s documentation for more detail.

Streaming APIs are not yet widely adopted but are useful as they enable external applications to receive notifications about changes in salesforce data. The use of the streaming APIs avoids the need of “frequent polling” into Salesforce via the REST or SOAP APIs to capture changes in Salesforce data. Streaming APIs also provide message reliability, that is, external applications can retrieve “event data” even after the event was emitted by Salesforce, which is very useful in synchronizing data between Salesforce and applications that are not permanently connected with it.

Streaming API is typically used to support data consistency and multistep processing, but it can also be used to address certain types of application/service composition issues (for example, to send notifications to mobile sales force automation applications).

​

Main Outcomes and Suggestions:

1. Because latency is a potential issue in synchronous API calls, minimize the number of synchronous API calls. Avoid highly building integration processes with serialized “record-by-record” synchronous updates because this causes slow system performance.

2. The Bulk API can be used for daily batch updates, but it can also be used for near-real time small-batch updates.

3. If synchronous SOAP API calls are necessary to meet the requirements of process integrations but the requirements have low to modest complexity, then consider connecting the integrations by using the Salesforce Partner WSDL, not the Enterprise WSDL. See Salesforce’s documentation for a definition of the two types of WSDL.

4. Salesforce has updated the capabilities of the Bulk API. It can now process millions of records in a single API call; organizations no longer have to break their API calls into jobs of 10,000 records per call.

5. Develop a set of integration patterns standards for your developers, one that defines when to use specific design types and timing considerations.

Acronym Key and Glossary Terms

CRM: customer relationship management

ERP: enterprise resource planning

HCM: human capital management

BI: business intelligence

MDM: master data management

​

​

​