How to refresh your Salesforce Sandbox environment

How to refresh your Salesforce Sandbox environment

Holly White on

Share with

LinkedIn
Twitter

Sandboxes are a great Salesforce tool to have at your fingertips because they allow you to create a complete copy of your Salesforce org in a separate environment. As sandboxes are completely isolated, they’re perfect for testing and training without harming your production environment. It’s vital to keep these development environments as closely synced to your production org as possible, to give you an idea of how changes will affect your live environment when they’re released.

But because the data and metadata in production and your sandboxes is constantly changing, they can quickly get out of sync. In this post, we’ll explain the different types of sandboxes and how you can keep yours perfectly up to date.

Types of sandbox

There are four types of sandbox environments, and you’ll want to choose different types for different uses. Each sandbox type has a limit on how frequently you can refresh them, ranging from once a day to once every 29 days. The storage sizes on offer also vary from 200MB to the same capacity as your production org.

Developer sandbox A Developer sandbox is intended for development and testing in an isolated environment. These sandboxes only include a copy of your production org’s metadata and have a limited amount of file and data storage of 200MB — but this is usually still plenty for most development tests and tasks. Developer sandboxes can be refreshed once a day.

Developer Pro sandbox The Developer Pro sandbox is similar to the Developer sandbox, but it can handle much larger data sets — with a storage capacity of 1GB. It still includes a copy of your production org’s metadata and it’s used for development and testing, including testing integrations and QA tasks too. Developer Pro sandboxes can be refreshed once a day.

Partial Copy sandbox A partial sandbox only holds a copy of the metadata from your production org, including a test sample of data – which is determined by a template. This is another test environment which is good for QA type tests, including acceptance and integration testing. Partial copy sandboxes can be refreshed every 5 days. The storage capacity on these sandboxes is 5GB.

Full Copy sandbox A full sandbox is an environment which provides a complete copy of your production org, including all data and metadata. It’s mainly used as a testing environment and is the only sandbox type to support performance testing, load testing, and staging. This sandbox has a storage capacity that matches your production org and can only be refreshed once every 29 days.

Sandbox management

Creating new sandboxes and keeping them up to date is a time-consuming task. Salesforce’s sandbox clone tool saves you from having to repopulate a brand new sandbox. The new sandbox will be an exact copy of the original sandbox at the time the tool was used – and will only need to be refreshed to match the production org. There are also sandbox templates which allow you to choose exactly which objects and data to copy over to your sandbox. These are only supported when working with Full or Partial copy sandboxes. Eventually sandboxes get to the point where a clean start is needed, and teams need to perform a sandbox refresh.

What does a Salesforce sandbox refresh do?

The main goal of a sandbox refresh is to sync everything to be an exact copy of your production environment. It’s possible to pull all the data and metadata from the source org using a sandbox refresh, but each sandbox type will copy different areas of production. If the sandbox is a clone or using a sandbox template, the refresh process updates the org’s data and metadata.

Syncing up your sandboxes is vital to keeping your tests as reliable as possible. If your environments don’t match up, you could miss errors and bugs that could then make their way into production.

How often should I refresh my sandbox?

Salesforce limits the frequency of sandbox refreshes, but refreshing as often as possible is the best way to keep your environments as closely matched as possible. If you’re using the Salesforce refresh process to sync up your sandbox, it can take several days to complete – especially if you’re working with a full copy sandbox. During this time you won’t be able to access your sandbox and a window of downtime should be scheduled.

How to refresh a sandbox with Salesforce

Refreshing your sandboxes in Salesforce is the traditional way to sync up your environments. This can be an effective option, especially if your orgs are really out of sync. Refreshing in Salesforce does have some pretty big limitations – which we discuss below – but can be done relatively simply:

  • In Salesforce, go to Setup > Data Management > Sandboxes. From here, you’ll be able to see a list of your sandboxes and a Refresh link next to them if they’re eligible to be refreshed.
  • Once you click the Refresh link, the status will change to Copying and you’ll receive an email once the sandbox refresh is complete.

Limitations of Salesforce’s sandbox refresh

Refreshing a sandbox is a pretty simple task, but if you’re doing it within Salesforce it can have some pretty annoying limitations:

  • Time: Sandbox refreshes can take a very long time, sometimes a week or more, to complete. This is dependent on a number of things including which sandbox type you are refreshing, the level of customization, and the server load or other refreshes waiting in the queue.

  • Lack of visibility: You can’t see what you’re overwriting in the sandbox, so you’re in danger of accidentally losing work that hasn’t yet made it into production.

  • Refresh limits: As mentioned earlier, Salesforce limits how frequently you can refresh your sandboxes. This can mean you’re waiting nearly a whole month between refreshes.

  • Replaced sandbox: The refresh isn’t strictly a migration to your existing sandbox; it tears down the old sandbox and replaces it.

  • Not always perfect: Some quirks in Salesforce mean your refreshed sandbox isn’t always an exact copy of production.

If you’re a small team with a slow and simple release pipeline, then Salesforce’s sandbox refresh might meet your needs, but most teams need more powerful tools like Gearset.

How to refresh a sandbox with Gearset

NOTE: Gearset’s comparisons have had an upgrade! We’re in the process of updating all our blog posts with the new UI images, but in the meantime you can find out more here.

Gearset can make your sandbox refresh run quickly, while giving you the control and speed to keep your environments in sync. Gearset won’t tear down your existing sandbox and replace it — instead we’ll compare your sandbox with production and deploy any changes.

Performing a sandbox refresh in Gearset can be done with in a few simple steps. Why not sign up for a free trial of Gearset and follow along?

1. Compare your orgs

Run a comparison between your production org as the source and the sandbox as the target. Make sure you select the Compare all metadata filter.

Compare your source and target orgs

2. Analyze the differences

As this comparison is different to the norm – production is the source and not the target – the New items tab will show you any metadata that’s in production but not currently in your sandbox environment. This will include any hotfixes made directly in your production environment. The Deleted items will show you the metadata in your sandbox that isn’t in production.

Analyze the differences between the two environements side-by-side

3. Decide whether to refresh

This is the moment when you decide if you want to go ahead with deploying changes from production. If your orgs are badly out of sync, Salesforce’s sandbox refresh is probably going to be the quickest option. If you do choose to refresh your sandbox instance in Salesforce, run another comparison in Gearset. A refreshed sandbox isn’t always totally in sync with production, and Gearset can help you get them closer.

Decide whether to refresh your sandbox

4. Deploy metadata

If your Salesforce instances aren’t too badly out of sync, you can select all the metadata changes in the comparison view and deploy them using Gearset.

Deploy metadata from production to your sandbox

5. Deploy data

Finally, use Gearset’s data deployment tool to deploy data from your production org to the sandbox. You can protect sensitive data and PII using Gearset’s data masking.

Deploy data from production to your sandbox

If you’re using CI/CD, then Gearset’s Pipelines tool is a game changer when it comes to keeping your environments in sync. Every time you promote changes along your release pipeline, Gearset will automatically create a pull request against upstream environments where the change hasn’t happened yet. Accept the pull request at the click of a button and effortlessly keep everything in sync.

Sandbox refresh best practices

When you’re ready to refresh your sandbox, it’s worth considering a few best practices to make the process run as smoothly as possible.

Choose the best time to refresh

Refreshing your sandbox can take anywhere from a few hours to several days. The sandbox won’t be available for the whole time, so choose a window which will minimize the amount of downtime needed.

Make sure everyone knows a refresh is happening

Announcing when the sandboxes will be out of action helps everyone plan how best to use their time. Make sure anyone who needs to know is notified in advance so that work isn’t interrupted or overwritten.

Use custom metadata types so they can be easily modified

Using custom metadata types instead of hard-coding data into your Apex will make it much easier to modify settings and values after refreshing. For instance, using an email address field instead of an email address will save you time in the long run.

Use the sandbox clone tool

If you need to refresh multiple sandboxes in the same way, then using the clone tool will save you time. By switching the source sandbox in the sandbox clone tool, you’ll copy the source sandbox and not your production environment.

Clean up your old sandboxes

Delete old sandboxes when you know you won’t use them again. Not only does this free up space, but it keeps your environments clean and reduces the chance of pulling on some outdated data. Be careful, though — once it’s been deleted you won’t be able to get it back.

Feeling refreshed?

Regularly refreshing your sandboxes can feel like an annoying task, but keeping them closely synced to production will save a huge amount of time and effort when you come to release your changes or run tests. Using Gearset to compare your sandboxes and orgs will help you decide whether you only need a few tweaks or would be better to completely refresh your sandbox.

And it’s not just sandboxes that need to be kept in sync with production. Struggling with Salesforce orgs and Git repos that are out of sync? Gearset’s pipelines can help you see your workflow from a birds-eye view to easily move changes up and down stream, giving you complete control of all your environments. Start a free trial today to get full access to the full platform.

Try all of Gearset for free