The False Native App
The False Native App
There is so much confusion in the Salesforce marketplace as to what constitutes a native application. Every day I speak to prospects who think they are reviewing native Salesforce billings systems, project management and accounting tools, and a long list of other applications to serve their business management needs. Unfortunately they are being greatly misled in most circumstances. When I ask them the names of the applications they are considering I often have to explain that they are not native to Salesforce at all, but instead have a native connector which is something VERY different. I have written this blog to help explain what it means to be native and why it is important.
Why there is so much confusion around being native
The crux of the problem is that being native is really not a black and white issue. There are many shades of grey. Sales Reps selling business management software want to make it a black and white issue to move you past this point in the sales cycle and focus on how their application will solve all of your business problems. The truth is that if you aren’t considering a fully native Salesforce application there will be one or several integration points to your Salesforce solution that will require design, development, and maintenance not to mention the burden of learning a whole separate API.
Defining what is Native
First off, lets define what is native. At Accounting Seed we define a native application as something that:
- Is 100% coded in Apex and Visualforce,
- Uses 100% Salesforce objects, either standard or custom objects
- Has no other proprietary API.
Currently there is only one accounting application on the Force.com platform that meets this criteria: Accounting Cloud. Financialforce is the only other application that comes close to this definition. Although Financialforce has written their application in Apex and Visualforce and uses custom objects, they fail to be native due to their proprietary API.
Why does it matter to be Native?
Being native is everything when it comes to the idea of a seamless, cohesive business process on a single platform. If you want to achieve the true synergy in having a single user interface, data model and security model for your entire organization then you need to have a native application. If it is non-native or has a proprietary API you won't be able to use all of the tools Salesforce provides like the data loader, import Tool, chatter etc.
The 5 tests for a native application
1. Can I run your application without Salesforce?
If the answer is yes, then the app is not native.
2. Is your application built out of any code other than Visualforce or Apex?
If the answer is yes, then it is probably not native.
3. Do you have a proprietary API
If the answer is yes, then it is probably not native or may be native but restricted in its use and your ability to integrate.
4. Can I use the Salesforce data loader or import tool with your app?
If the answer is no, then it is probably not native
5. How many screens have you over-ridden with Visualforce?
If the answer is the majority or many then it could be a native app, but difficult to integrate with.
What Salesforce should do about the problem
Salesforce needs to reorganize the Appexchange between native applications and integrations. This will bring much more clarity to users and allow them to find native apps verses preconfigured integrations much more easily.
