The na14 outage on May 10 has raised a lot of discussion around trust in cloud applications, data backup strategies, and even outage clauses with SaaS vendors. The analogy that comes to mind for me is an airplane crash. While it’s a tragedy with very graphic scenes, people keep flying since air travel remains one of the safest modes of transportation. And losing transactions for 3.5-4 hours is certainly graphic from a business operations perspective.
In response to the outage, I’m getting asked interesting questions from the Salesforce community and LinkedIn on external data strategy, which is my area of expertise. I actually had not considered this question until after reading the coverage, but can external objects save your organization from future outages?
What Are Salesforce Connect External Objects?
Salesforce Connect was introduced a couple of years ago to provide seamless real-time access to back office systems, so organizations no longer have to copy data into Salesforce to be treated as native objects. These federated objects are accessible via OData and called external objects.
Will Salesforce Connect Protect Me from an Outage?
No. Salesforce connect provides data integration and federation, not high availability.
Would It Have Helped to Recover Lost Transactions on May 10?
Yes and No.
We'll start with how it would have helped. Let's say your external objects are setup against an Oracle database behind the firewall and a Postgres database hosted in Heroku. If those transactions were made completely on external objects, the transactions would be persisted to Oracle or Postgres for which external objects were created. So there would have been no data loss on those objects on May 10, unless your external databases were also down. But if both Salesforce and your external databases happened to be down at the same time, there are probably bigger things to worry about than data loss.
Now for how it wouldn't help, at least not from the perspective of any data persisted in the Salesforce platform. Any updates made on standard fields with indirect relationships to external objects would still be lost. However, updates made on external object fields would be preserved in Oracle and Postgres, and you would be able to figure out what parent objects may have been updated from external database transaction records.
Best Practice for Salesforce Connect and Outages
We run Salesforce on na13 and I trust Salesforce. Salesforce Connect is not a high availability strategy, and trying to run an entire Salesforce org as external objects just does not make sense. But, I am a big proponent of this technology for its intended purpose of allowing flexibility for Salesforce orgs to configure where the data resides for a single version of truth. As a best practice, I continue to recommend that we keep our Salesforce data in Salesforce, and our remote data sources in external databases exposed as external objects.
If you’re new to external objects, you can check out my tutorial published on Salesforce Developers to learn more.