Why Your Enablement Needs To Be Native on Salesforce

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

Lots of tools in your sales tech stack integrate with Salesforce and push and pull data in and out. The heart of these integrations are Salesforce’s various APIs.

Companies can use Salesforce’s APIs in two main ways - only the API (e.g. via an integration user), or with a managed package.

API integrations

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.

Non-native managed packages (non-native apps) 

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: 

• Provide some functionality within Salesforce
• Bring in data via the same APIs as before
• Maintain the majority of the tool off of the platform.

A good example of a non-native managed package is the G2 Connector, by G2.

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.

Pros and cons of non-native tools 

API-only and non-native managed packages integrate to Salesforce the same way. That means they have similar pros and cons.

Pros of non-native tools

• You can use mission-critical tools for which there is no native Salesforce app. For example, if you’re a mechanical engineering shop, you need specialized software to design your product. There’s no way to design the same complexity inside Salesforce. So it's better to use the tool you like, and still be able to push and pull data with APIs.
• You can custom-build products and still share data. If your needs are so specific you need to build your own tool, APIs let you use Salesforce data without confining yourself to force.com
• Data is only going in, not out. Most of us want to use Salesforce data in other applications, tools so bi-directionally is ususally standard. If you do only need to push data into Salesforce, though, you may consider a non-native application. 

Cons of non-native tools

Non-native tools, while there is a much wider selection of options, have some significant limitations:

• Limited data sharing between systems. Most APIs limit what data syncs over to Salesforce and vice versa. Not all data in each tool is exposed to the API, meaning that you can’t pull everything together.
• API limits. There is a limit to how much information is pushed over an API in a given time period (e.g. how many API calls a tool can make). The result is that data can take days to sync over as it waits in the queue.
• Security vulnerability. There are security risks associated with APIs. If you're syncing with another tools, data is being stored off of the Salesforce platform. Every time your customer's data is stored in a new database, your security risk increases.
• Potential breakages. Because APIs depend on mappings, if the data changes in one system, it can cause the integration to fail. 

A Salesforce native app 

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.

Easy to use data

There’s absolute overlap with Salesforce’s common object data model.

• Even if your native app uses custom objects, there’s still perfect data transfer and manipulation.
• You can analyze Salesforce data and custom app data together, without any insights lost due to data being held back over.
• You get to use Salesforce’s massively powerful reporting tools – tools you / your RevOps team already know how to use.

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.

Secure, compliant, reliable

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:

• US Department of Defense (IL4)
• GDPR
• ISO 27001 and 27017
• HIPPA
• SOC I and SOC II

... 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.

Fast time to value

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.

Maximizing value

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.

Enablement + Salesforce native apps

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.

Bullet-point Summary

• A Salesforce native app is built and lives on the Force.com platform. That means they use the same data, same security, and reliability, and can use lots of the Salesforce out-of-the-box functionality.
• Non-native apps either live off the Salesforce platform and use APIs to pass data back and forth, or use a managed package to bring some functionality into Salesforce while still relying on those same APIs to share data between the systems.
• Non-native apps have a wider range of applications, since there are far more tools that are not on Salesforce then are. But they come with downsides, like security, API limitations, data syncing, and clunky implementation.
• Native apps, while there are fewer of them, cover the vast majority of use cases and give companies the data security they need, allow for better data analysis and manipulation, and get to value faster.
• For enablement teams who want to track enablement consumption, non-native apps are more than good enough. For organizations who need to prove the impact of their sales enablement programs on revenue, then a native enablement tool is the way to go.