What is a Native Software Integration and Why Does it Matter?

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 TargetRecruit, selling a Salesforce-based ATS. I’m also back to using Salesforce as my internal CRM.

When I joined the team, my main goal was to find a sales automation solution. A previous customer recommended Groove to me. 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. I didn’t have to worry about the data transferring between Groove and Salesforce whenever I made a change. 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 the 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 the door open to other apps/systems.
• Latency – The system needs to transfer data changes in order for them to be reflected immediately. 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 bi-directional? 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 burden a system and be expensive for vendors. They may charge more for extra calls or limit the number of calls, resulting in 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 fonts, and a less-than-desirable scrolling functionality

I don’t think API integrations are all bad. More than 75% of the partners in our ecosystem use them. It’s important to know the advantages and disadvantages of native integrations to understand their power. 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. It’s a software solution with developer tools that can be expanded and built upon. If you want more information, read the article exploring 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 Isimio (scheduling), Accounting Seed (General Ledger), BiznusSoft (HR/Payroll), CloudComp (Commissions), DataTrim (Duplicate Checking), Mogli (SMS), 3B Onboarding (Document Generation and Onboarding/Credentialing) 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 flip side, 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 fewer 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, makes 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 in 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 its 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.