We live in a connected world. That’s the cliché, right? Applications talk to each other, exchanging data, performing complex tasks seamlessly – at least, that’s the promise. The reality doesn’t always match up with the hype.
It may seem curious then, that we’ve designed all of our applications to date to be native to the Salesforce platform. That means they run entirely on Salesforce. There’s no integration between systems – just the one system. No synchronization of data – just the one database. No shared authentication, just the one standard Salesforce login.
One Source of Truth
It may seem a bit old fashioned I suppose, in our connected world. It may seem limiting – after all, if we’re native on the platform, our applications can’t work with other CRM systems – they really are optimized to work with Salesforce CRM.
On the other hand …
It’s nice to have just one system. You don’t have to worry about data integrity between systems – what if they are out of sync? Or there was a delay pushing data from one to another. With us, there is just the Salesforce database – one source of truth for everyone from sales to marketing to the executive suite.
Higher Security, Less Risk
Better yet, there’s only one system to secure. There’s no need to worry about security on other systems, because your data never leaves Salesforce. Fewer systems means less risk, because as you well know, these days any system is potentially vulnerable.
There’s just one login – the Salesforce login. No need to track logins on outside systems. No need to grant outside systems API access into your Salesforce org. No need to trust and hope that the outside application is using secure design patterns.
But even that’s not the entire story. This is Salesforce – where the security model is deeper and richer than that of any other platform. There’s role based security – with support for complex record sharing rules. There’s object level and field level security based on user profiles. When you’re a native application, you have access to that for free, and can build sophisticated security scenarios that both respect and build on that infrastructure. It’s a lot harder to do so if you aren’t native, and often requires you to provide access to Salesforce using a high privileged account – another account whose security you get to worry about.
It’s Nice to Be Native
There are a lot of things nice about being a native Salesforce application. Nice for us, and nice for our customers. Don’t get me wrong – it’s not all wonderful in every way. Writing native applications is hard – trust me, it would be a lot easier to build applications on outside servers where we could draw on nearly limitless computing resources, or at least as much as we and our customers were willing to pay for. Finding technical people with the skills to write high end native Salesforce applications is tough. But, we’re good teachers, so we manage. And the benefits are worth it.
Salesforce has built a software development platform that is second to none. And when you think about the benefits, including having a single shared database and a single and consistent security model, it’s hard to see how anyone would want to do anything other than stay native.
