Salesforce is a very powerful platform for managing customer relationships (CRM). The only way to truly make it an effective CRM is to connect it to where the sales, support and operation teams create data.
Salesforce Integration – Planning & Documentation is part of the blog post series: Integrating Salesforce With Other Apps – A Series! Integrating Salesforce with other applications or sources of data can be difficult.
The first step for successful integration is understanding the goals, planning and documenting the current processes. The most important thing is to understand the stakeholders and what they need to do with the data.
Know What the Expected Outcome Is
A clearly defined strategy is absolutely critical for system integration to be successful. A clearly defined strategy is only possible when we know what the expected outcome is.
For the most part, the expected outcome will be either revenue growth, cost savings or easier access to information.
Interdepartmental collaboration is the key to successful software integrations. All of the stakeholders need to be involved in the process relatively early so that needs and gaps are identified early.
While working with your stakeholders it’s really important to spend the time and determine what the standard terms and vocabulary are in each system. For example, how are dates stored in the source system versus Salesforce.
It usually makes a lot of sense to include someone from customer support fairly early if it will impact customers.
Know the Limits
Salesforce, because of its multi-tenant nature has some pretty restrictive limits that can cause a great deal of difficulty for integration. Integrating systems is risky and difficult if we don’t take the time to understand how the other system works and how it will work within Salesforce.
Questions we should be asking are:
- Will it send us a lot of data per batch?
- How often will it be sending us data?
- Do we need to be sending ourselves the data that frequently?
- Does it need to be a Push or pull?
- Does it need to be a two-way integration?
What type of Integration
When building and planning an integration, it’s imperative to know if the connection to Salesforce will be a one-way integration or a two-way integration.
If it’s a one-way integration, Salesforce will call the other system’s api or the other system api will call Salesforce. If data changes in one system and it’s unlikely to change in the other. This might be okay with the stakeholders. If the integration is a data platform like a data warehouse it’s very likely that Salesforce will push to it and the data will almost never change.
A two-way integration involves both systems calling one another and usually trying to keep the data in sync between both systems. For the most part, you probably want to use a two-way integration most of the time.
Will the integration be coded by your team or by someone else? If it’s by your team you might want to look at using something like MuleSoft and trying to avoid the need to write code.
Salesforce offers a variety of different APIs if it needs to be hand-coded. For the most part the options are SOAP or REST. The data format is usually XML or JSON although there some other options.
|API Name||Protocol||Data Format|
|REST API||REST||JSON or XML|
|Analytics REST API||REST||JSON|
|Bulk API||REST||CSV, JSON or XML|
|Apex REST API||REST||JSON, XML, Custom|
|Apex SOAP API||SOAP||XML|
If your company needs a high level of security (ie an ERP to Salesforce Integration) the SOAP API should be the preferred choice. If you are using a type safe language (like C# or Java) or have a system that only supports XML you should use the SOAP API.
The REST API is probably the way to go if you need a quick way to integrate with Salesforce and will be using it to modify some data.
If you need to do any custom logic after pushing data into Salesforce the Apex REST API, aka custom Apex REST Class is the way to go.
If you are sending large volumes of data and can handle asynchronous communication than the Bulk API makes a lot of sense. The Bulk API is based on REST principles and designed for large data sets.
I’ve blogged previously about the different Salesforce APIs that are available.