By Bobby Bartlett

Years ago, while working for a previous employer, I started using a sales automation tool called Outreach.io. I was part of the team who evaluated this tool along with SalesLoft and Yesware. I really liked Outreach because it structured my prospecting efforts and automated various tasks. However, a major issue I found was the less than desirable Integration with Salesforce. The integration was bi-directional, and I never knew what to put in either system or why. As a result, data always ended up in the wrong place. Fast forward a few years and here I am at TargerRecruit, selling a Salesforce-based ATS. I’m also back to using Salesforce as my internal CRM. 

When I joined the team, my first priority was to adopt a sales automation solution, and a past customer of mine referred me to Groove. During my first evaluation of Groove, I immediately noticed a considerable difference. It had all the same functionality as Outreach, but it also had a Native integration with Salesforce. That means, whenever I made a change in Groove or Salesforce, I never needed to worry about the data transferring to the opposing system. It was seamless and instantaneous. 

This situation has led me to think, “How many others out there aren’t familiar with native integrations and their benefits?” Over the next few years, this level of integration is only going to gain demand. Therefore, it’s important to break down the difference between API integrations (which is current state for most) and native integrations.

API Integrations

Today, most of us use integrations created through an API, or Application Programming Interface. This was the next generation of integrations before native integrations came along. The major issues with API integrations include:

• Security – API Integrations can be vulnerable to malicious attacks and are often targeted by hackers. Once compromised, this potentially leaves to door open to other apps/systems.
• Latency – Data changes are not reflected immediately in the system they need to transfer to. API calls are usually set to be made intermittently. 
• Duplicate Data – The age-old question is, if I’m using both systems, which system do I put the information in? Is it one way or bidirectional? This can wreak havoc on your data if you don’t have solid processes and people who abide by them. 
• Heavy Tax – API calls can heavily tax a system, and cost a vendor money, so it’s not unusual for software vendors to upcharge for additional API calls (or even reduce the amount of calls, causing less data syncing).
• Additional Overhead – Maintaining an API is time consuming. For example, if something in the API changes, these updates must be carefully coordinated with the consumers of the API. Any communication breakdown can cause integrations to break.
• Slow iFrames – Since every time a page that requires an API call opens it must call to a server elsewhere, it will slow your page load times. Also, the graphic and functionality within the iFrame will slow page load times as well.
• IFrames Look Bad – IFrames generally don’t flow with the aesthetic of a page. They might have different color buttons, different font, and a less than desirable scrolling functionality. You know what I’m talking about.
  

I don’t think API integrations are all bad. More than 75% of the partners in our ecosystem use them. However, I do think it’s important to understand the pros and cons so you can understand why native integrations are so powerful. With that said, I also think it’s important we cover the different types of native integrations that are out there. 

Types of Native Integrations

Before we dive in, we need to identify what a true platform solution is. In short, it’s a software solution with a strong set of developer tools that is designed to be extended and built on. If you want more information, click here to read an article I wrote on what a “platform” is vs. a “point solution”.

So, there are two kinds of native integrations. One is built directly on a platform, so we call it “platform”. The other is built on a native connector, which some call a “native integration”.

1. Platform
TargetRecruit is an example of this. To call us an integration with Salesforce would be slightly misleading because in essence, we are Salesforce. We use their objects (like the Account and Contact), their reporting, their workflow automation, all their admin tools, etc. Other examples of tools built on the platform in our partner marketplace are Skedulo (scheduling), Accounting Seed (General Ledger), BiznusSoft (HR/Payroll), CloudComp (Commissions), DataTrim (Duplicate Checking), Mogli (SMS), Conga (Document Generation) and KonaSearch (Deep Search). 

Here are the characteristics of a platform solution:

• Allows for a more seamless user experience since you don’t have to manage a separate login and all your data lives in one place.
• Easier for end users since they only need to interact with a single user interface vs. learning multiple.
• The common object model allows the merging of objects. This makes for smoother information sharing between native apps because the common data is not replicated. For example, TargetRecruit (ATS) and Salesforce Sales Cloud (CRM) both share the Account and Contact objects. Thus, any data entered on an Account record in Sales Cloud will be seen by a TargetRecruit user because both solutions share that common object. With an API integration there would have to be a mirrored object or data set sitting on the other side to pass the information to.
• A lower cost because if you’re using an integration through an API you have to double up on licenses since there are no common objects. Users would have to have a license for each solution. On the flipside, an organization using Salesforce Sales Cloud for their sales team could just buy TargetRecruit licenses for their recruiting team because both will still be able to see what’s happening on the Account and Contact/Candidate objects.
• Security. Simply put, the less places your data is housed, the less susceptible you are to a security threat. Having it centralized in Salesforce, which has clients like the US Navy and Department of Defense, make it pretty secure!

2. Native Integration

A native integration is the most intriguing integration solution to me. This is also a topic I rarely find that tech folks are familiar with. This will gain popularity because it doesn’t inexorably tie your technology to that platform (like building on platform) but it’s a much better user experience than a regular API integration. As a 3rd party vendor integrating with a platform solution (like Salesforce), you can use developer components and toolkits to embed your solution within that platform. In other words, the 3rd party vendor’s software now takes on the look and feel of that platform solution, and the functionality is essentially built-in so your end users can live on the platform solution. Some examples of applications with native connectors are the aforementioned Groove (Sales Automation), Able (Onboarding), and Essium Xenqu (Onboarding). 

Here are some characteristics of a native integration:

• The integration’s architecture is built on a managed package which allows your data to exist real-time in the platform environment so there is no data latency.
• This also eliminates the need for a bi-directional sync.
• It allows you to use the specific platform developer tools to build within that platform’s confines in your instance. For example, Salesforce has their own developer tools and languages they’ve created to allow customizations to live more in harmony within a data set, or ‘Org’ as we say in Salesforce-land.
• Prevents API surges that push you over your Salesforce limits.
• Lowers compliance risk for GDPR, CCPA, and other global privacy laws.

So What?

Today, out of the 3,900 apps in the Salesforce AppExchange, there are 417 that are natively integrated with Salesforce. If you click on that link, you can click the checkbox for “Native” on the left-hand side to see what they are. Although Salesforce is known to have by far the largest partner ecosystem, it’s not the only one of its kind. For example, Microsoft is known to have a platform solution and has invited some to build technology on top of their stack. I’ve even heard of one or two applicant tracking systems being built on top of Dynamics CRM.

In conclusion, when building a tech stack, consider how to reduce logins and make the experience for your end users as seamless as possible. Avoid unnecessary, multiple logins. What’s the best way to do this? Strongly consider a true platform technology.