In building a sales stack to help drive your revenue team’s success, an important consideration is whether a solution application is a native Salesforce app. Depending on the buying criteria, it can be a major factor in an investment decision.
Never has an organization’s sales tech stack been more important. New, digital-first buying journeys require revenue teams to revamp their processes, and an increasingly competitive marketplace places a premium on efficiency.
As organizations scale their go-to-market (GTM) processes, they are increasingly turning to automation to better manage speed, accuracy and costs of their motions. Those automated technology solutions eventually lead to a discussion on where applications are hosted and where data resides.
This post goes through the advantages and disadvantages of native Salesforce and non-native Salesforce applications.
What is a Salesforce-native app?
A native Salesforce app is an application built upon the Salesforce platform (aka, Force.com). It is 100 percent coded within Salesforce using Salesforce objects, and uses a Salesforce API rather than a separate, proprietary API. Unlike non-native apps, no connectors or traditional integrations between the platform and the app are required.
Conversely, non-native Salesforce apps are solutions that reside outside of the SFDC platform. One of the biggest problems posed with non-native apps occurs with data syncs, which can be especially messy.
Below, we’ll cover the merits of Salesforce-native versus non-native on the following potential buying criteria:
- Data security
- Data accuracy
- Reliability
- Efficiency
- Trust
Data Security
With Salesforce-native apps, data never leaves the Salesforce platform. Because data is not moved off the platform, it cannot be breached through hacking attempts on less-secure servers.
Non-native apps, on the other hand, require one or more integration points to an organization’s SFDC instance. Therefore, each must be carefully managed to ensure security is maintained.
Edge: Salesforce-native apps.
Data Accuracy
In SFDC-native apps, as there is no separate system to align with, your data is always in sync with your Salesforce instance. The common object model that native Salesforce applications use is consistent across applications and Salesforce products, providing confidence that all data transactions are correct.
Edge: Salesforce-native apps.
Reliability
When Salesforce runs, SFDC-native apps run too. When SFDC is running, there isn’t a risk of a native app going down and not working – the entire infrastructure is managed by the Salesforce team.
For non-native apps, a separate sales stack needs to be maintained, presenting an additional point of potential failure. If an issue arises with either platform, either SFDC or a complementary platform, all revenue processes get impacted. Even if neither system goes down, APIs still must be continually maintained to ensure the two (or more) platforms are communicating correctly. A communication hiccup could lead to the creation of duplicate records, the alteration of incorrect records during automation, or a simple failure of the non-native platform to process records.
Edge: Salesforce-native apps.
Efficiency
An inherent advantage of Salesforce-native apps is they allow users to avoid managing multiple complicated integrations to non-native software. Salesforce, itself, updates with three scheduled releases a year, and native applications prepare for those updates in advance. Because native applications are built upon Salesforce, processes can be streamlined, such as provisioning new users or limiting their access to resources immediately. Additionally, all native applications are built upon the common object model, making it even easier for native applications to communicate with each other without additional code or connectors.
Non-native apps require APIs or connectors to be individually maintained for off-platform tools to continue communicating properly. This takes an often costly investment of time, especially if one of those platforms has a poor technical support team or business process. Additionally, user licenses have to be maintained separately with the off-platform app and not instantly in sync with your users in Salesforce. Finally, their access to resources will also have to be carefully managed in the separate app as well. All this additional management can lead to operational inefficiencies.
Edge: Salesforce-native apps.
Trust
SFDC-native apps are required to adhere to Salesforce Security policies. Additionally, without a separate platform and any need to manage communication between platforms, you can rest assured that you won’t encounter any hidden fees for maintenance or management.
Non-native apps require close scrutiny on how a solution provider accesses and uses customer data, as well as its pricing structure. Separate legal and security reviews will be required for additional platforms, and any changes to policy will need to be carefully reviewed.
Edge: Salesforce-native apps.
When picking a technology solution, the most important consideration is its performance. Will the application provide the value you seek for your revenue team processes?
However, when primary considerations like performance and costs are relatively equal, where an application sits with respect to data security, data accuracy, reliability, efficiency and trust makes all the difference. In those cases, the SFDC-native application most often proves the better choice.
Is it ever better to have non-native SFDC apps in your tech stack?
A non-native application, off-platform, can be a better solution if an organization has such a unique business model that its revenue processes cannot be effectively served by the Salesforce platform. The risks, challenges and costs associated with an off-platform solution still exist, so the total cost of ownership must be more carefully balanced with the expected gains of such a platform. A best practice is to keep processes managed by such an off-platform tool to a minimum, to only those which absolutely must be performed off-platform.
Determining if an app is 100% native to Salesforce
All certified native Salesforce apps have a Native App icon listed on their AppExchange product pages. As an example, below is the Features table from LeanData’s own AppExchange listing:
If Salesforce doesn’t provide its Native App designation, it’s not a 100 percent SFDC-native app.
If you’re still not certain an app is 100 percent native, answer the following three questions during your due diligence period:
- Where is the app hosted?
- Where is the app data stored or processed?
- Is a connector required in order to use the app with Salesforce?
If the app is hosted on or if its data is stored or processed on an outside server, not within Salesforce itself, then the app is not 100 percent native. A Salesforce-native connector would not be needed to use a Salesforce native app.
Summary
All other considerations being equal, native Salesforce apps are generally more favorable. A 100 percent SFDC-native app keeps your data safe and does not require any custom coding. Additionally, because there is no need for managed connections or for additional user log-ins, a native app usually presents a simpler solution.
When users log into Salesforce, they can immediately receive access to installed native applications. Additionally, training, adoption rates and usage all become easier because users only need to learn one Salesforce interface.
Don Otvos
Don Otvos is an experienced Operations professional with a deep understanding of the people, processes and technology that support the revenue journey. Don has held various operations roles at companies including Salesloft, Yammer, Mulesoft, and Netgear. Connect with Don on LinkedIn.
