In our Salesforce Sandbox guide, we discussed what sandboxes are and the different types. We also shared that when you conduct a Salesforce sandbox refresh, it clones metadata from the source org, which overwrites anything in that sandbox you were working on, but didn’t deploy.
‍
In this article, I’ll share some of my best practices around preserving that work and keeping your sandbox and source org in sync.

What happens when I refresh a Salesforce sandbox?

Refreshing a sandbox means updating your sandbox to match what’s in your production org. More specifically, you’re cloning the configuration and metadata from your production org into an existing or new sandbox org. This is typically the first step you’d take in setting up a development environment and release pipeline because before you begin building, you’ll want to know you’re building on the most up-to-date configuration.
‍
When should you refresh a sandbox in Salesforce? Here are eight best practices:
‍

1. Choose a refresh “window” that minimizes  downtime
‍

For each sandbox, you’ll want to determine a window for running your refresh, say, two days, during which, that sandbox won’t be available.
You’ll want this because Salesforce sandbox refreshes take time. The more realistic the sandbox (that is, the more of your actual production configuration and metadata it contains), the longer it takes to refresh. Thus, you’ll want to plan your refreshes carefully.
‍
Here are some factors to consider:

• The type of sandbox. How often can you refresh each Salesforce sandbox? As our sandbox guide explains, different sandbox types have different limitations on how often they can be refreshed. (A minimum of every five days for a Partial Sandbox, a minimum of every 29 days for a Full Sandbox, and so on.)
• Whether you’ve developed things there that haven’t been pushed into production. Refreshing the sandbox will delete all that metadata.
• If it’s a Full Sandbox, whether anyone else is using it for training or research. Maybe they need more time to complete user acceptance testing (UAT).
• Whether a Salesforce release is imminent. See best practice number seven, below.
  

Also, when refreshing sandboxes, you’ll have to spend some time configuring them to not point to actual production endpoints, like your ERP, or to not include actual customer emails. If you don’t alter or mask these things, your sandbox can still connect to your ERP or generate emails. If it actually syncs or sends to that list, it could be disastrous.
‍
Making these configuration changes naturally slows your development process, as you won’t be able to (or shouldn’t) use the sandbox for development until you are sure that you won’t accidentally send real emails.
‍
In sum, plan your refreshes to minimize downtime for both people developing new features and those conducting UAT and training.
‍

2. Communicate your Salesforce sandbox refresh window early and often
‍

Having decided on your refresh window, ensure all parties know about it in advance. Send an email summarizing what’s happening, how long it will take, and why it matters to them. Your list should include:

• Admins and developers using the sandbox
• Others using it for UAT and training
• Product owners who will be impacted by the downtime in your development process
  

Be sure this doesn’t clash with important project deadlines. There’s nothing worse than sticking to a refresh window that erases something critical mid-development cycle.
‍
What do you do during that window? Communicate that too. This is a great opportunity for you to work through your non-development backlog of activities, like soliciting feedback from users, conducting a post-mortem on recent launches, and reaffirming your roadmap.
‍

3. Use custom metadata types in production, so they’re easily modified
‍

Oftentimes, teams will hard-code information into their workflows and Apex triggers. For example, they may use a specific sales manager’s email address in every reply-to field. Instead, I recommend creating a custom setting or metadata type that functionally says, “Fetch and insert sales manager’s email here.” Do the same for your endpoints. When everything’s a custom metadata type or setting, it’s much easier to modify once you’ve refreshed your sandbox, and want to change those emails or endpoints.
‍
If you don’t do this, the masking will add long, tedious hours to your work.
‍
For example:

• Use custom settings and/or custom metadata types to specify email addresses, integration endpoints, etc. It’s a lot easier to modify these values post-refresh than having to manually inspect all the metadata that references these data points, and change them. (Which also adds risk—you might break those configurations.)
• If you are using custom metadata types, consider having two records per metadata type—one for production and one for sandboxes. Your Apex classes can then use the IsSandbox property to dynamically choose which metadata type to use at run-time. This is a huge time saver because your Apex classes will basically do the work for you.
  ‍

4. Create a post-refresh checklist

As you learn what needs to be done after refreshing a sandbox to mask sensitive data or remove production endpoints, make a checklist, and update it as you go. Post it somewhere where the entire team can correct and add to it.

Or, even better, have one of your developers record a screen share video of the entire process and make it mandatory viewing for new hires.
‍

5. Use the Sandbox clone tool to duplicate refreshed sandboxes

All the above practices will help you speed up your post-refresh activities. But what happens when you have to repeat this for five different sandboxes? (One for UAT, integration, etc.) The simple answer is cloning.
‍
With sandbox cloning, you can conduct your post-refresh process (thanks to the post-refresh checklist video) once, in a dedicated sandbox, and then clone that sandbox as many times as you like. This will create new sandboxes that mirror the configuration and metadata of the original sandbox, not the production org (which contains all those unmasked emails and endpoints).
‍

6. Automate some activities using the SandboxPostCopy interface
‍

Salesforce provides the SandboxPostCopy interface that you can use to create Apex classes that are automatically called when your sandbox is created. This is a great way to automate certain tasks such as:

• Masking users’ and contacts’ email addresses
• Updating custom settings/custom metadata types (using the Apex Metadata API Wrapper)
• Create test data
  ‍

7. Ensure your refresh window aligns with Salesforce’s own release window

Salesforce will automatically upgrade your production and sandbox orgs multiple times a year. They typically refresh your sandboxes before they refresh your production orgs, to enable you to test new features or conduct regression testing to ensure your configuration still works in the new release.
‍
Depending on when you conduct your Salesforce sandbox refresh, you may accidentally refresh it based on that newer release, which doesn’t match your production org. This may or may not be what you want, and can throw everything off.
‍
Read the sandbox preview instructions for more information on how to decide when you refresh your sandbox.

8. Copy your configuration data too

When using apps from the Salesforce AppExchange, it’s common to find that it must be configured using records from custom objects, as opposed to via the setup menu. For example, if you are using Conga Composer for document generation, all its configuration (the templates, what objects to use as data sources, etc.) are all configured in custom objects. This also applies to Salesforce CPQ and your own internal apps may follow the same pattern.
‍
This is known as reference data or configuration data. The challenge with this pattern is that when you create a new sandbox that does not include data, these apps won’t work. So all sandboxes except for Full Sandboxes will have to be re-configured before you can use these apps in those environments.
‍
Because this configuration is stored as data as opposed to metadata, it cannot be deployed using change sets or any other Metadata API tool like ANT, or Salesforce Developer Experience (SFDX).
‍
Instead, you need to import it using the Data Loader or Import Wizard. And if the data has lookup or master-detail relationships, suddenly you are dealing with a multi-step data migration job because you’ll need to insert the parent records before any child records. This can make your configuration data deployments extremely difficult and error prone.
‍
(With Salto, you can treat configuration data as metadata, and it can be deployed alongside metadata. This simplifies the deployment process as you have a consistent approach to metadata and configuration data.)
‍

Set windows, communicate them, and don’t forget to save your configuration data

If you’re following the eight best practices, you’re well on your way to creating a Salesforce application lifecycle process that allows your team to increase your feature quality. Your sandbox refreshes won’t interrupt people’s work, Salesforce’s releases won’t interrupt yours, and you can reliably launch features that work in production.