Overview of Integrating with Salesforce

October 12, 2017

For a while now, I’ve been meaning to write about integrating with Salesforce. What motivated me to do it is a colleague asking me today: “Hey Luke. I have a system that has to write data back to Salesforce. What are my options?”

What’s an Integration?

An integration is when two or more systems talk to each other to accomplish something.

Two common integration types are

  • Single Sign-On (SSO)
  • Data Exchange

Single Sign-On (SSO) Overview

With Single Sign-On aka SSO, a user signs into one system, typically using their username and password, and then they’re able to sign-in automatically to other systems that are connected to that system without having to sign-in again.

The system where one signs in is known as the “Identity Provider”, or in some circles the “IdP”.

SSO Common Examples

  • A company’s website uses Salesforce as an Identity Provider. When someone tries to access a secure webpage on the website without being signed-in, they’re redirected to the Salesforce login page or community login page. After successfully signing in, they’re redirected back to the requested, secure webpage and are able to view it.
  • A Salesforce community allows one to login to the community using their favorite social media site such as Facebook, Google, Twitter, LinkedIn, etc. This is commonly known as “Social Sign-On”. It’s still SSO but with a social network as the identity provider.
  • An employee has signed in to their work computer and are automatically signed in to Salesforce. The most common example of this is when a company uses Active Directory and when you sign-in to your computer, you’re also signing in to the employer’s network. Since Salesforce can be configured to use your employer’s Active Directory for SSO, it’s a seamless experience to automatically sign-in to Salesforce.

SSO Technical Options Overview

API / Forms Authentication 

A system has a login page in it that accepts a username and password. When someone clicks “Sign In” or “Login”, the system calls the identity provider’s API passing in the supplied username and password, and if they’re signed in, their user information is returned to the calling system and they’re signed in. This used to be the most common way to do it before Open Id and other more secure protocols were created.

OpenID with OAuth2

In my experience, OpenId with OAuth2 is now the default SSO protocol used because it’s more secure and has become widely adopted. The High-Level handshake goes like this:

  1. User tries to access secure webpage and isn’t logged in so user is redirected to the Identity Provider’s website.
  2. The Identity Provider asks the user if they’d like to authorize that system to connect to this system. If they “allow it”, then they’re redirected to the Login page.
  3. User signs in and is redirected to the originally requested secure webpage on the other system along with a user token aka a special sign-in value.
  4. The original system takes this user token and asks the Identity Provider for the user’s information. The identity provider passes back the user’s information such as their name, contact information and possibly security information so the system knows what they have access to.

The primary advantage that this protocol has over “Forms Authentication” is that the users are only entering their credentials on the Identity Provider and the third-party systems never see a user’s credentials. This makes it more secure.

That’s the very quick gist of OpenId. Take a look at the OpenID with OAuth2 Documentation for more information.

SAML

SAML is another common SSO protocol but seems to be less adopted than OpenId. It’s pretty similar to how OpenId works but uses XML and assertions instead of JSON. See the SAML SSO Implementation Guide for more info.

Data Exchange

Data exchange is when two or more systems share data. There are many reasons why two systems would share data. Some common examples are:

  • The company’s e-commerce site integrates with company’s back office system to grab product information and to handle order processing.
  • A company replicates its data from many systems into a central data warehouse so that Business Intelligence software can do various analytics on it.

Data Exchange Models

There are three common models for exchanging data between systems:

  • Push
  • Pull
  • Middleware

Push Model

In a “Push” model, one system tells another system directly here’s the data to use and do something with it such as insert, update, or delete it.

This is most often used for “Real-Time” integrations where as soon as something happens in System A, System B is notified by System A. This allows the two systems to remain synchronized faster. For example, an order is submitted on the e-commerce site and then the site immediately tells Salesforce there’s a new order for that customer so it gets saved in Salesforce too. Another example is an account record is created in Salesforce so Salesforce does a callout to the data warehouse to replicate the data.

Pull Model

In a “Pull” model, one system asks another system directly for information.

This is often used for synchronizing large amounts of data that doesn’t have to be updated frequently because it doesn’t change often or it’s ok if the data isn’t exactly the same for a little while. One example is the data warehouse asking Salesforce for all the latest CRM data that’s changed in the last day.

Middleware

A third system sits between two systems that have to exchange data but the two systems don’t directly communicate with each other. All data flows through the middleware. This can be beneficial because this specialized software is able to handle large volumes of data using various methods and typically doesn’t require any coding. They also usually have pre-built integrations for commonly integrated systems.

Examples

Data Exchange Methods

Now that we’ve covered the high-level models, let’s talk about how the data is exchanged.

Importing & Exporting with Files

This manual process requires someone to generate a file with the data to exchange in System A and then manually import it into System B. One common format is a comma separated value aka CSV file. One can even manipulate the data using common tools such as Excel before importing the data into the target system.

With Salesforce, one can use reports and even listviews to generate export files that can then be imported into other systems.

Pros
  • Usually easy and fast to implement.
  • Good for data that doesn’t have to update often.
  • Salesforce has decent out-of-the-box features for exporting and importing data.
Cons
  • It’s manual so people are involved so this can be slow and error prone.

Application Programming Interfaces (APIs)

An API allows another system to programmatically talk to it without human intervention.  There are different types of APIs such as REST and SOAP but for this overview, we’ll be skipping over those technical differences.

The primary benefit of having an API is that one or more external systems are able to use it to communicate with the system using a standard set of “services”.

Salesforce Enterprise / Partner APIs

The Enteprise and Partner APIs are standard APIs provided by and maintained by Salesforce so that external systems can Create, Read, Update, and Delete records in Salesforce. They come in SOAP and REST versions and are good for handling up to thousands of records at a time.

Salesforce Bulk API

This Salesforce provided API was designed to handle up to billions of records. It’s asynchronous and typically harder to use than the Enterprise or Partner APIs because multiple services have to be used to accomplish a single operation.

Salesforce Custom APIs

Developers can use Apex to create custom APIs that external systems can use to talk to Salesforce. This is typically done for more complicated scenarios and processing that the Enterprise, Partner, and Bulk APIs can’t handle alone.

API Pros
  • Multiple external systems can use the same API to communicate with the system.
  • No human intervention required.
  • Could potentially be easily consumed with standard middleware tools without coding.
API Cons
  • Creating good APIs are hard and time consuming because
    • they require good documentation so other developers can easily use them.
    • it takes a while to design and implement.
  • Often require developer level technical abilities to use.

Salesforce External Objects

This declarative option allows Salesforce to connect to an external system’s API, as long as that external system uses the OData protocol, to create, read, update, and delete the external system’s data from within Salesforce. The data is read and manipulated in real time from within Salesforce without having it stored in Salesforce.

Pros
  • Declarative and fairly easy to set up.
  • Uses object tabs and listviews to interact with the data.
Cons
  • Expensive. I hear it’s like $3-4 thousand per external object. If I’m way off, please let me know.

Salesforce External Services

This declarative option allows one to provide a “service schema file” to Salesforce using a particular format and Salesforce is then able to call an external system’s API using Flows. At the time of this writing, this feature is still in Beta.

Pros
  • Declarative and looks easy to set up.
Cons
  • ?? – Let me know in the comments since I haven’t used this option.

Resources

There are other ways to integrate such as using Canvas Apps and inbound email services but they don’t seem to be used much in my experience.

What did you think of this overview? Are there other integration options? Let us know in the comments.