Did you know that sometimes apps that are not completely native can be listed as native on the Salesforce AppExchange? Or that Salesforce’s sharing and security rules apply to all native apps? Choosing between apps that are native and non-native might seem like a minor decision, but there’s some critical information behind it. Here’s what you should consider:
When an app is native…
It runs 100% within the walls of Salesforce.
- NO data leaves the platform, so Salesforce’s sharing and security rules are always applied to the 3rd party application.
- It has a similar look and function to Salesforce.
- It does not count against your API usage limits.
- You will never experience a service disruption – if Salesforce is up, the app is up.
- No consultant or deep IT involvement is typically needed to get set up.
When an app is not native…
It does not run entirely within Salesforce.
- Data leaves the platform. There is no guarantee to your data’s security like there is on Salesforce, because Salesforce’s sharing AND security rules are NOT applied.
- Interactions with the 3rd party app will count against your API usage limits; if it causes you to reach those limits, it will render the app inoperable.
- It may go down even when Salesforce service is up.
- Consultant or IT involvement is typically necessary to set up.
It may still be listed as native on the Salesforce AppExchange. Sometimes organizations click “Native” if only a portion of their app was built on Force.com.
Detect false natives by:
- Watching for instances where you’re asked for permission to send data outside of Salesforce. This means the app relies on third-party servers, and your data will be sent to that third party.
- Asking if the organization contracts to a Web hosting company to manage their app.
You should consider:
- Asking who might have access to your data and how that access is controlled. (This includes application logs.)
- Finding out if the organization is SAS70 certified and what their security protocol is.
- Running a deep technology audit of the organization.
- Figuring out how updates and maintenance would work.
- Exploring any other external risks of bringing the app into your Salesforce org.
I mostly disagree with all your points:
A native app is not necessary using the Salesforce looks and feel.
It counts in terms of API.
When the app is non fully native as you define it: you don’t need consultant necessary, the app is as secure as a native as it goes through the Salesforce security review