On vs Off Platform Solutioning

Introduction

Salesforce has grown so much from their early days of B2B sales management / CRM software. The product offerings have grown through good old fashioned product development and a lot of spend on acquisitions. That makes for a LOT of options for designing a solution for your organisation - option overload, sometimes.

We architects need to be able to weigh up options and make best practice recommendations for the right solution for a particular use case and set of parameters (e.g. existing landscape, architectural standards, ongoing solution support strategy, budget, timeframe...). This includes knowing what aspects of your solution should be on-platform or off-platform.

There are some requirements that just don't fit Salesforce core - by which I mean your Sales/Service/Experience (+ other stuff) cloud instance, your main org. I'm talking about the kinds of requirements that are going to make you hit governor limits, or place significant strain on the processing capability of your org. In these scenarios, you need to look off-platform. At the risk of sounding like I work in Salesforce marketing - going off-platform doesn't always mean moving away from the Salesforce family of products, there are many options that are not part of Salesforce's core platform (but that do plug into it) that provide key functionality, like Marketing Cloud (ex. ExactTarget), Commerce Cloud (ex. Demandware), Heroku... but Salesforce isn't the be all, nor is it the end all, and in fact there's some merit in diversifying your enterprise tech stack so your eggs are not all in one basket.

Enough exposition, now I'm going to give you some examples of common requirements that will require you to consider off-platform solutions!

Data Backup / Data Recovery

By definition, when you're backing up your Salesforce data for business continuity / disaster recovery purposes, it must be backed up off-platform. Salesforce tried recently to get rid of their Data Recovery Service and have reversed that decision after the uproar from their customers - but I fully expect that reversal to be reversed again at some stage in the future (although that is just a reckon, I don't actually know anything about this).

There are lots of products you can use that have covered standard Salesforce data backup and recovery requirements again and again - Odaseva, OwnBackup, Grax.io come to mind. You can also build your own data backup quite simply if you wish - but that's not the hard part of disaster recovery. The hard part is the actual recovery of backed up data, and in a normalised database structure like Salesforce, it can take a long time to fully understand and replace all of the parent and child records that may have been corrupted or lost.

Whatever you do, if you're thinking about using Salesforce's weekly backup export service, you might as well just not bother.

TFW you think a 7-day-old series of CSV files is an adequate data backup and recovery solution.

Data Archiving

Often conflated with data backup and recovery is a sister requirement - data archiving. This, too, by definition requires off-platform storage of data in order to free up storage space (be it data or file) in your Salesforce org.

Some of the products that provide data backup and recovery also provide archiving solutions, too. You can also virtualise archived data by way of external database and the use of external objects, such as a Heroku PostgreSQL DB + Heroku/Salesforce Connect, if you're in the mood to build this yourself.

Large Data Volumes (LDVs)

This is an interesting one. What constitutes an LDV? Well, no one actually has a hard and fast answer to that one. Basically, if you have optimised your queries and processing as much as possible (e.g. using skinny tables, selective or even async SOQL queries, Bulk API for integrations, etc) but you're still seeing slow load times / timeouts on queries or page loads like reports or dashboards, then you've probably got an LDV problem. From what I can pick up this is generally an issue in the millions of records, although I did see a snapshot of an org recently that had something around 60 million Accounts and their org was still functioning, so who knows!

Salesforce do have an answer to on-platform LDVs, but it's got some heavy considerations. They offer Big Objects, which allows you to store lots and lots of records - but you need to build custom UI to be able to interact with your Big Object data table/s, and Big Objects aren't available with processes, flows, or apex triggers.

An alternative to that is external objects, which I mentioned in Data Archiving above - where you store your LDVs in a database externally and display that data in your org on demand. External objects behave fairly similarly to your standard or custom objects within Salesforce, and it allows you to only grab or update the smallest amount of data needed to complete the users's task - like viewing a report, viewing a related list of child external objects... that sort of thing. Virtualising data in this way greatly reduces the volume of data that is required in your Salesforce org at any given time, and unlike Big Objects, external objects play nicely with automation tools and your OOTB Salesforce UI.

Public Website

You can provide unauthenticated, public access to Salesforce Experiences (I'm still not used to calling Communities by their new name, but doing my best!) - but be careful about the volumes of expected visits to your unauthenticated pages and what your guest visitors are going to want to do. There are all sorts of considerations to take into account like the fact that you will have limits on the number of visits your Experience receives on a monthly basis - 1 million/month for an Unlimited Edition org, and 500k/month for an Enterprise Edition org. If your guests need to create, or interact with data, there are all sorts of rules around guest user access and ownership of data, too.

Heroku is a Salesforce off-platform option I'd look at here - one of it's core uses is creating web apps that can rapidly scale when you have large volumes of visitors. It's not the only option for your public website, of course, there are tons of non-Salesforce products out there as well. Just don't try and wedge a high volume public website into Experience Cloud :)

Document Management System

Salesforce actually have a bunch of different ways you can store files. They even have a handy tool to differentiate between the options - Differences between Files, Salesforce CRM Content, Salesforce Knowledge, Documents, and Attachments.

However, file storage is expensive in Salesforce, and depending on what your average file size and retention rules are, you might find yourself unable to upload files that are too large - or uploading lots of average-size files and running out of room. Also, most of the options available only provide part of the normal suite of document management requirements - like governance, collaboration, security and access control, version control, audit trails and document check-in/check-out or locking functionality.

You can consider Quip as an option (it certainly nails the collaboration requirements) - or go outside of the Salesforce family and look at one of the many DMS systems that have pre-built connectors into Salesforce that are on the AppExchange.

Just in General, Doing Stuff That Hits Those Pesky Governor Limits

Sometimes, you need an app to be able to perform some functions that require more time, memory, or data volume processing power than Salesforce provides you, via their pesky governor limits. There are sometimes on-platform alternatives you can use, like choosing asynchronous integration options or scheduling batch Apex.

The architect and dev communities are all waiting and watching for what Salesforce Functions (FKA Evergreen) will bring and if this will be the solution we're looking for, for scaling massive processing - but for now, you'd want to look at something like Heroku or similar to provide an off-platform solution.

Summary

Salesforce provide a truly incredible platform for Sales, Service, CRM, business process automation... but no one platform can be everything to everyone - it's important to know when to go off-platform, in order to maintain the integrity of the holistic solution.

Have you got another example of when it's a good idea to solution off-platform that I've missed? Tweet me @heyemilyhay.