Summary: non-native apps integrate with Salesforce using APIs, and that can cause problems. If tieing enablement to revenue is important, then a Salesforce native app built on Force.com is the way to go.
We’re going to break down the most common ways sales enablement tools connect with the platform. That way you'll know what to look for when you’re thinking about your enablement tech.
Here we go!
How do non-native tools share data
Companies can use Salesforce’s APIs in two main ways - only the API (e.g. via an integration user), or with a managed package.
The first method that non-native tools used to pass data to Salesforce is via an API. They don’t build anything in Salesforce. Rather, they leverage the APIs to move data back and forth.
Outreach is one example of an API integration.
It works by maintaining two databases and linking them with APIs. This allows Outreach to create and update Salesforce data as activity happens.
The second major integration you see is a non-native app with a managed package.
That means the application is not built on Salesforce, but has developed some technology that lives on force.com . APIs to connect the managed package to the core application.
With a managed package, companies can:
G2 is the tool and is not built on the Salesforce platform.
G2 Connector is a managed package that you install to bring G2 functionality into Salesforce.
With the G2 Connector, companies can pull data from G2 into Salesforce and use it in different ways.
Another example is LinkedIn Navigator.
The Navigator managed package gives you an iframe on the account page layout. This lets you see from within Salesforce people who work at an account you're looking at.
But again, the LinkedIn Navigator tool exists independently from the Salesforce platform.
API-only and non-native managed packages integrate to Salesforce the same way. That means they have similar pros and cons.
Non-native tools, while there is a much wider selection of options, have some significant limitations:
A Salesforce native app is like the managed packages from earlier. The only difference is that it's built on top of the Force.com platform. That means that the tool functions 100% within the Salesforce ecosystem.
So from the interface all the down to the servers where data is stored, it’s SFDC all the way.
There's an important point to make here.
Salesforce and a Salesforce native app don't need to integrate.
They are already in the same system.
It would be like talking about the integration between two parts of the same product.
Like how accounts and contacts in Salesforce integrate together.
Or how the Netflix menu and the Netflix video player integrate.
Because it's all the same system, it all works together.
Of course, some Salesforce native apps (including us) can use the Salesforce APIs to talk to other products. But working with your CRM data requires no integration.
And that has a lot of perks.
There’s absolute overlap with Salesforce’s common object data model.
And because it’s on a single dataset, you’re only ever viewing data in different ways, rather than recreating or duplicating data in a new system. This reduces the likelihood of duplicate data and makes data maintenance much easier.
A Salesforce native app lives on Salesforce’s world-class infrastructure, which means that you get all the security, reliability, and trust of Salesforce. For example, the Salesforce platform has the following certifications:
... Plus about 20 more. It’s a very, very secure platform. And native apps have the same security because data never leaves the system.
Same for reliability – if Salesforce is working, then your native app will probably be working too.
With no integration work or new systems to deploy, native apps are up and running faster. Plus, since it’s all in Salesforce, there’s a lot of baked-in knowledge from an admin and end-user perspective. Ultimately, these reduce your time to value significantly.
Justin Browne, the Head of Sales Strategy, Operations, and Enablement at Workato, said in a recent MSP webinar:
“If you don’t have your [sales] tech stack integrated and automated it can not be optimized... the sum of the tech stack must be greater than the parts.”
And here, a Salesforce native app will have a significant leg up.
Because a Salesforce native app generates all its data on the Salesforce platform, you can slice and dice it however you want. You can look at data in different ways, giving you cleaner insights on what’s driving your business.
So what does this mean for sales enablement solutions? Should you get a native salesforce app for enablement, or should you go off-platform?
It depends on what you’re trying to achieve as an enablement team.
What are your enablement goals, and how are you going to know if you achieve them? How do you measure success?
We advocate an outcome-based enablement approach.
This means that the enablement function's goal is to help the sales hit their revenue targets, and their contribution is attributed back to specific enablement activities.
If that’s the case, then you want your enablement data as close as possible to your revenue data, which means a Salesforce native app is the best solution.
If, however, enablement at your organization is more focused on inputs rather than outcomes – for example, how much content was produced, how many training sessions were run, etc... – then a non-native app will probably give you the insights you need.
Spencer is the product marketing manager at LevelJump. He comes from the world of content and loves helping B2B SaaS companies find exactly the right people who love a product, and figuring out exactly how to tell that product story so it resonates and compels action. You can find him on LinkedIn.