When working on a Salesforce client project, hours upon hours are spent in the client’s Sandbox. The Sandbox is the “practice” org that allows us to test implementations, modify data, or update dashboards before fully committing to these changes in the real Salesforce org (aka deploying to production). But this practice requires a few important things, one of which is to never refresh the Sandbox while someone is working in it.  A Sandbox refresh would erase all of the work being done and is nearly impossible to recover (more on that later). We had a recent “learning moment” that led us to reiterating and outlining some Sandbox best practices for our clients (or anyone working on solutions for future deployment in a Sandbox). 

A Real-Life Scenario

We had been working in a Sandbox for a client as part of a long-term project. We had been building our solution over about eight weeks, and we were just preparing to deploy when the unthinkable happened — an AppExchange vendor who wanted to demo their product to our client refreshed the Sandbox while our team was working! There was confusion and miscommunication between our client and their AppExchange vendor that led to these missteps, and the end result was a lot of headaches, minor panic, and a nearly impossible recovery mission. 

As of July 2020, Salesforce no longer recovers data or metadata (functionality) in the event of a loss. Knowing this, we were not optimistic about retrieving the lost Sandbox work. We immediately contacted Salesforce Support in the hopes that they would see our ticket and be able to restore what was lost within the tight 48-hour window. Thankfully, our story has a happy ending. Salesforce was able to recover our lost Sandbox. and we were able to salvage our work. But this is not a common result and is a good reminder to stay up-to-date on these Sandbox best practices:

Understand Who’s Working Where

Any Salesforce customer utilizing Sandboxes for development and configuration work with plans to deploy to production should have a strategy for keeping Production and Sandbox setup menu changes in sync and for communicating to the team who’s working where. Communication is key to preventing mishaps that could cost your development team (whether they are consultants or internal team members or a combination of both!) lots of time and rework. 

Have a Deployment Plan

Deploying from a Sandbox to Production can range from very simple to very complex, depending on what you’re deploying. From changesets to robust deployment tools, there are many options for orchestrating and automating deployments. That being said, there are almost always manual steps, data migrations, and communication that must happen to ensure deployments don’t disrupt users and business processes. Creating a deployment plan with steps, dates, assigned responsibilities, and dependencies is always a best practice when moving functionality from a Sandbox to Production.

Use an External Backup & Restore Solution

When it comes to backing up data and metadata in your org, using an external data backup is highly recommended. While Salesforce does offer scheduled backups, these backups are lacking in functionality for two key things: metadata and restoration. That means that Salesforce’s scheduled backups only back up your records. They do not back up your functionality or settings. 

Using an external backup and restore solution is best practice for both Production orgs and Sandbox orgs where development is taking place. There are many options out there, but two systems we recommend are Odaseva and OwnBackup. Odaseva allows you to backup and restore data while protecting the integrity or privacy of the contents. You can also automate data archiving to maintain best performances for the system. OwnBackup proactively prevents data loss through their automated backups of critical data and metadata. Their continuous monitoring will alert you of any anomalies that need to be reviewed or addressed. Remember: the primary cause of data loss is human error; it’s better to be proactive than sorry!

Backup Your Data During Migrations

While backup and restore solutions take intermittent data backups at set times during the day, there are various data import/export tools that allow for data backups and snapshots on the fly.  Data Loader is a Salesforce client application that allows you to manage the bulk of importing or exporting data. Dataloader.io is another user-friendly tool that performs similar functions. You can utilize it for inserting, updating, deleting, or exporting Salesforce records. For the import feature, it pulls from .csv files or database connection. When in export mode, it will produce .csv files. Some useful features include drag-and-drop field mapping, support for all objects including custom objects, support for large files, and an easy to use wizard interface for interactive use. 

In Summary

The best course of action is to have a proactive contingency plan addressing communication, deployment, and data/metadata backups before embarking on projects that require significant customization and automation. Outlining your strategies for contingency planning prior to a project kickoff means everyone involved is on the same page about the importance and steps necessary to ensure project success. While these tips are all steps in the right direction, remember this: The primary cause of rework or data corruption is human error. So don’t feel silly if you have Plan C, D, and E in your back pocket!