Have you considered buying a revenue operations and intelligence (RO&I) or sales engagement platform? If so, you’ve likely seen vendors touting the benefits of their native Salesforce capabilities. That’s a good thing, right? Most clients I’ve spoken with believe a native application is a positive feature. Vendors know this and look for any opportunity to attach their products to this term. As a result, the definition has become unclear.

I asked more than 10 vendors their definition of “native” and received nearly 10 different responses. So let’s start with the basics. Salesforce defines a native application as “an app that is built exclusively with setup (metadata) configuration on Lightning Platform. Native apps do not require any external services or infrastructure.” The confusion is over native functionality versus a completely native application. Vendors that have a native capability such as direct write-back to an object say that they are native. This is partly right but doesn’t rise to the level of “native” by Salesforce’s definition. I would argue that this isn’t a bad thing. Native applications are not a universal positive. They have advantages and disadvantages that must be evaluated to determine whether they are beneficial for your specific use case.


  • Direct write-back. Native applications write directly into CRM instead of syncing from one system to another. This avoids sync issues that happen with even the most sophisticated syncing capabilities. It also eliminates API calls, which is important, because Salesforce imposes limits on the number of calls a company can make without having to pay additional fees.
  • Security. Salesforce has a well-earned reputation for being a secure platform, making it valuable to have a solution that is covered under its security umbrella. Salesforce fully covers native application security because it is 100% within the Salesforce ecosystem. Non-native tools require an additional review to validate they have the same level of security. Non-native apps may be fully secure — or not. Do your due diligence to ensure a non-native app meets your security requirements.
  • Improved Salesforce user interface. Native applications allow buyers to enhance the Salesforce user interface, making it easier to use them within the CRM ecosystem. This is valuable for companies that want to improve functionality without adding new applications to the tech stack.


  • Leveraging data outside of Salesforce. Native applications struggle to manage heavy use of external (non-Salesforce) data. While CRM can be the source of truth for account contacts and opportunities, it is not the source of many of the interactions between the buyer and the seller (even if they have ways to store this data through custom objects). Intent signals, cadences, and web conferencing happen outside of CRM, so they need to be attributed to CRM objects. CRM may be the hub for customers, but it is not the source of interactions.
  • Handling computation-intensive algorithms. Native applications struggle to handle computation-intensive requirements. AI and machine-learning algorithms are computation-intensive and are critical to unlocking value from sales tech solutions. Sacrificing computation capabilities to have a native application limits the value of the application; consider this when choosing a solution.
  • Optimized user experience. CRM system interfaces have a reputation for being difficult to use and overly complex. Many believe that they are more so a place to log information than an efficient work environment for the seller. While native solutions can improve the interface of these systems, they are also bound by them. Many non-native applications offer seller interfaces built to be seller-friendly and focused on improving reps’ ability to execute their day-to-day tasks. Companies must decide whether it is better to have a native application or a more feature-rich solution developed outside the Salesforce ecosystem.

So is “native” a must-have? Our recommendation is to look deeper. Identify the native capabilities that best support your use case and buy the product that meets those requirements. For example, if you need direct write-back capabilities for the objects that are most important for you, in addition to the ability to execute complex analysis of unstructured data, a fully native solution is not right for you. Native is a capability to evaluate, not a must-have feature.