Learn about Salesforce sandbox refresh best practices in our comprehensive guide. Understand the process to refresh a sandbox and tools to sync metadata with production.
In this comprehensive guide, we'll be taking you through the process of Salesforce sandbox refreshes, including how often they should be done, why they're important, and how to carry them out. We'll delve into the benefits of keeping your sandbox data and metadata in sync with production and explore some of the challenges you may face if you don't refresh regularly.
Here are our 5 key takeaways:
According to the Salesforce Development Lifecycle Guide: “We recommend that you refresh your sandboxes periodically to ensure that they have current configuration information and data.”
The ability to refresh a sandbox is a beautiful thing, however unfortunately this guidance leaves a lot unanswered. Periodically? Does that mean once a day? Once a week? Once a quarter? How often should one really refresh their sandboxes?
It goes on to advise:
“Refresh your UAT sandbox environment periodically to ensure that the partial data copy has current data.”
And:
“Refresh your Developer sandboxes as needed. For instance, developers can refresh their sandboxes to have a clean copy of the organization’s configurations and metadata that they can use as a baseline and add customizations to.”
(Emphasis is ours.)
As needed. Periodically. Again it’s a bit vague. Let’s look into sandbox refreshes in a bit more detail.
Salesforce enforces limits on how often sandboxes can be refreshed.
Full Copy sandboxes contain all of your production data. Accordingly, Salesforce places heavy restrictions on how often you can refresh them. For Full Copy sandboxes, you can refresh once every 29 days.
Partial Copy sandboxes contain only a fraction of your production data and so can be refreshed more frequently. Still, it’s not something you can do daily. Partial Copy sandboxes can be refreshed every 5 days.
If you delete a full Full or Partial Copy sandbox you must wait 29 or 5 days to create a new one respectively.
Developer and Developer Pro sandboxes can be refreshed once per day. This is useful if you are looking to implement continuous integration.
Salesforce sandboxes are one of the most underused assets that any Salesforce development team has. Even teams that are making effective use of sandboxes are still often neglecting refreshes. Because of the fairly extreme limits on sandbox refreshes, many Salesforce teams vastly neglect and undervalue them. The infrequency of refresh availability means that updating your sandbox is not often top of mind, and the importance of regularly refreshing your sandbox is often lost.
Salesforce sandbox refreshes are all about making your development environments - whether they are Full, Partial Copy or Dev sandboxes - mirror production as closely as possible. When you perform a sandbox refresh, the data in your sandbox is pulled from production to make the sandbox as close to accurate as it’s type allows (i.e. a Partial Copy sandbox will never look exactly like production because it is limited in the number of records it can hold).
Having accurate data is useful when developing because it allows you to feel much more confident that your code and configuration changes will not break your production instance. So much of Salesforce is tied directly to data and testing your features against accurate data is a good idea.
But sandbox refreshes also bring down metadata changes. This is also very important. Not only do you want the data in your sandbox to match production, you also want the metadata to do so. This is a place where many teams are fairly out of practice.
You want your metadata to mirror production because this makes merging code and configuration changes much easier and less harrowing.
Take for example a tale of two sandboxes. The business has a feature request which requires an Apex trigger update and a new custom field to be added. Sandbox A has been recently refreshed from production. It’s metadata is exactly the same as what is in production. Sandbox B has been worked on by multiple developers and has not been refreshed in over a year (this may seem extreme but it is actually unfortunately common among Salesforce developers).
But metadata refreshes are just as important as data refreshes for keeping your development environment in sync with production.
When it comes time to migrate changes from Sandbox A to production, it will go smoothly. The only differences between the two orgs are the changes that you are looking to deploy. So there is no danger of overwriting metadata in production, and no danger of dependency issues creating bugs or other challenges.
The story is not so simple for Sandbox B. Sandbox B doesn’t just differ from production in a few ways, there are in fact hundreds of unused classes, triggers, fields, and Visualforce pages that are on the sandbox that are not present in production. When we test our new feature on our sandbox, it looks good. No issues are seen. But when it comes time to deploy, we’re going to be nervous. How can we be sure that the new feature won’t mysteriously break in production because of a dependency issue?
This challenge is a big part of why so many teams are pushing towards continuous integration for Salesforce. Making small frequent changes and keeping your developer and test environments in sync with production minimizes the risk of bugs and issues. When you deploy massive changes that were tested on an environment that looks nothing like production you can easily run into trouble.
Refreshing a Salesforce sandbox is simple. Simply go to Setup > Data Management > Sandboxes. Here you will see a list of all sandboxes. Sandboxes that are eligible for refresh (see the above limits) will have a “Refresh” link next to them. When you click the Refresh link the status of the sandbox will change to “Copying”. Salesforce will email you when the refresh is finished.
Once this is done you will need to activate your sandbox to make use of the changes. You will see that the status has changed to “Replacement ready”. To make the refreshed sandbox available simply click “Activate”. Note that all data and metadata will be lost in the sandbox once you do this.
There is no way to recover this information unless you are using a tool like Blue Canvas to track your source control.
The simple answer is: as much as possible within the limits that Salesforce provides. Why don’t teams generally do this?
For starters, sandbox refreshes can take a long time. There is no clear definition for how long it can take, but this Stack Exchange post on Salesforce sandbox refresh timesoffers some guidance:
It may take a week or even more for the Sandbox refresh to complete. There’s also another article, that I cannot find currently, that mentions that there are two types of refreshes, namely “slow” refreshes and “fast” refreshes. Simply put, if you have a larger data volume, you may be placed into the slower queue, while if you’re doing a configuration-only refresh, you might end up in the “fast” queue. The specifics for what qualifies for each queue is not publicly mentioned, and is probably tweaked periodically to provide maximum performance.
Salesforce performs sandbox refreshes in a queued fashion so the length of your refresh will depend on the size of your org, how customized it is, how much data is in the org, number of objects and configuration choices, and server load.
It can take a few minutes to refresh a small sandbox if you time it right, but it can also take days or even over a week if you try to refresh a large org during peak hours.
Another reason people don’t refresh sandboxes regularly is that they don’t remember to. CRM Science’s Alex Sutherland recommends using simple Google Calendar reminders to make sure you are doing sandbox refreshes on a regular basis. It takes 2 minutes to setup and will allow you to take better advantage of refreshes for years.
Salesforce provides limits to the number of refreshes you can do because of the data load on their servers. But metadata refreshes are just as important as data refreshes for keeping your development environment in sync with production.
Fortunately, you can use our Salesforce Deployment Tools to continuously sync your sandboxes with production without doing full refresh cycles. This allows you to get in the habit of refreshing daily which will both improve code quality and make deployments much simpler.
Blue Canvas uses Git to track all changes. You can quickly merge changes from production into your sandboxes in a matter of seconds by using our Deployment Requests feature or simply issuing a git pull salesforce master command on the command line.
To learn more about how to refresh metadata on Salesforce, sign up for an account or email team@bluecanvas.io, or get in touch with us directly and learn about how Blue Canvas can work for you.
--------
What is a Salesforce sandbox refresh?
How often should I refresh my Salesforce sandbox?
Why is refreshing my Salesforce sandbox important?
How long does it take to refresh a Salesforce sandbox?
How can I remember to refresh my Salesforce sandbox regularly?
Can I refresh metadata separately from data in Salesforce sandboxes?
How do I refresh a Salesforce sandbox?
