An Intro to Salesforce Integrations

As you first dip your toes into the waters of Salesforce, you’ll probably start to hear the word “integration” over

2 min. read

As you first dip your toes into the waters of Salesforce, you’ll probably start to hear the word “integration” over and over again. Part of a core vocabulary, integration refers to the act of tying an external application to Salesforce to add functionality and connect your data sources.

Simple idea, but how does it actually work?

In this post, we’ll look at three different kinds of Salesforce integrations and the general pros and cons of each.

Salesforce Integration Type #1: Native

Native integrations are those that pair Salesforce with external applications — think LinkedIn or Microsoft Outlook — via pre-written code. These connections exist for one of two reasons:

  1. The producer of the external application wanted to make it easy for users to connect their product to Salesforce
  2. Salesforce wanted to make it easy for their users to connect to this particular application

Native Salesforce integrations are meant to work out of the box, and it shouldn’t take you very long at all to get them up and running. Plus, you’ll likely be able to count on customer support in the event that you encounter a problem.

On the flipside, you’ll be giving up significant customization ability. Because solutions are hard-coded, these types of integrations only allow certain pre-built settings to be changed. If you want to change something outside those settings, you’ll be out of luck.

(Note: Native integrations should not be confused with native Salesforce apps, which are built directly on the Salesforce platform, and therefore don’t need to be integrated).

Salesforce Integration Type #2: Middleware

Middleware refers to an intermediary platform — hence, middleware — that can be used to create a connection between two other applications (Salesforce being one of them, as far as our purposes go). These user-friendly tools empower architects to design integrations without needing to use code.

Examples of middleware include Workato, Dell Boomi and Scribe. They allow for greater customization while still offering bonuses like tech support and integration templates. These services will charge a monthly or annual fee, and that’s on top of what you’ll pay an architect to create your integration in the first place.

Salesforce Integration Type #3: Custom

Custom Salesforce integrations are like middleware integrations, but without the go-between platform. For fully custom integrations, you’ll need a developer capable of connecting to Salesforce’s API purely in code.

Because these types of integrations don’t rely on a third-party platform, they maximize the potential for customization. That said, they’re often the most complicated, time-consuming and expensive. Any time the integration needs to change or something breaks, you’ll need a developer.

Making a Decision

If you’re still feeling overwhelmed, try to remember: Making the right integration choices has less to do with understanding granular technical details and much more to do with understanding your company’s needs.

When it comes to Salesforce, take time to understand your process and pain points. Is there a functionality that you’re missing? Do you have other sources of data currently trapped in siloed applications? If so, are there native integrations available to connect these other applications to Salesforce? These are the questions that will guide your way forward.




Danielle Sutton