Simple tasks to ensure that critical customer data and metadata is properly protected when executing a major or minor release to production in Salesforce
While this subject seems to be a no brainer for most experienced Salesforce consultants, this happens much more than we care to admit. We are constantly building solutions that have many moving parts managed by, potentially multiple, teams located throughout the world or even in the same building. Configuration is constantly being pushed through the various development streams culminating in a release to production. Even with the best controls in place, one team may have had an end user ask for a simple configuration change to be made and it does not make it into the formal release documents…
It happens let’s not beat around the bush.
…The next day the release manager, who may have been up until the wee hours of the morning, gets a series of frantic calls/texts about the fact key sales data has been wiped out and teams are furious.
Taking a breath and clearing my mind of this unfortunate situation…
This happens way to often to the best of us but taking a few extra minutes in “planning the execution” could have saved you a world of pain.
I cannot tell you the number of times I hear “oh we’ll just push this tonight after 8pm and we don’t need a plan of action”. No matter who you are and what your skill sets may be, a deployment needs a few things to be successful: Planning, participation and sound execution. The first part of that. “Planning”, is not simply compiling a list of objects to migrate using a change set. As I mentioned before, what happens if a business SME asks the dev team “I really think that text field should be a number field” that is great, but then the simple act of this will have a catastrophic impact to the existing data housed in that field.
Rewinding the clock…I guess I may be dating myself a bit, but in my early years of technology development and project planning came during the run up to Y2K. Disaster Recover (or DR) strategy was a critical part of any system change or system plan one would work on. Having a backup, no matter what, was a critical part of the deployment planning and execution. The Salesforce ecosystem has many simple tools available to us when it comes to DR planning. The simplest is the ability to take a back-up of critical customer data before execution. The number of times I have gotten a call from teammates saying “I am not sure what happened but the customer is complaining that this data is missing” and they are scrambling to recover this critical information.
Backing up the key objects:
A task that should be in any deployment plan is to do a simple data export using either the built in data export feature in Salesforce (see this link) either on demand or on a scheduled basis (depends on your org type) or using a 3rd party data tool such as MuleSoft’s dataload.io. By simply taking an export of the critical objects (account, contact, case, opportunities…) it will give yourteam peace of mind against a critical data loss.
Backing up metadata:
Beyond the loss of customer data, losing a key business function and trying to unwind where things may have been changed can eat up hours critical business time. The configuration management lead can give the overall team some comfort by taking a simple metadata backup. Like data backups, there are several ways to address this task. Easiest of which is to create a sandbox copy using a simple development org in between releases. Once the release is complete and is being used, at that point another refresh of that metadata baseline can be captured by refreshing the dev org.
There are many ways to achieve these simple goals, noted in this document, but at the end of the day it is all about being prepared for these critical issues. I hope this helps you plan properly for your future releases.
If you are interested in learning how we can help you do the same, reach out to [email protected]. Also, check out our other blog posts at https://appsassociates.com/.