Your Salesforce sandbox offers a safe space to simulate adjustments and data configuration in a risk-free manner. Mirroring production, sandbox serves as a pre-production stage to help you understand which field changes may affect other fields and workflows within your org.
If you’re a Salesforce admin, you know just how often you need to make quick changes in production. According to Sonar’s average customer activity, admins make an average of 400 changes to their Salesforce org every month… that’s a lot of changes!
Your work is usually time sensitive as well, so it’s completely understandable why every change can’t be made in the sandbox first.
However, this quickly makes your sandbox a poor reflection of your production and can lead to more significant issues— even potential breaks– down the line. This means you should refresh your sandbox on a consistent basis.
Wondering just how often you should refresh your salesforce sandbox?
You can use Salesforce change management tool like Sonar, Or,Learn the signs and best practices for refreshing below.
Helping Ops pros refresh their sandbox with confidence.
Try Sonar Free
What Does Refreshing Salesforce Sandbox Do?
Refreshing your Salesforce sandbox copies customizations, data, and configurations from production to your sandbox. It makes your test environment accurately reflect your production version so testing and development teams can work in a realistic environment.
Your admins should be refreshing the sandbox every so often to keep the most up-to-date, relevant metadata for your organization’s use.
When Is It Time to Refresh Your Salesforce Sandbox?
As a Salesforce admin, we know you are strapped for time and bombarded with “urgent” requests from all sides of the GTM team on a daily basis. We sympathize with you.
However, jumping into production to make quick fixes will only make your life more difficult in the long term if those same changes aren’t replicated in your sandbox.
Consider yourself lucky if you haven’t learned this the hard way already. To help ensure you don’t learn this terrible lesson, here are a few of signs it’s time to refresh your sandbox:
- You’ve made several configuration updates to the production org
- You’ve updated passwords and other data
- You’re working on a new solution for your team that requires updated fields
- You’re building a new form that requires specific custom fields that may have been updated recently
Remember, the true purpose of refreshing your Salesforce Sandbox is to ensure it’s a spitting image of your production. So if you’re guilty of making changes in production before the sandbox, this is your cue to run a refresh! Additionally, you can manage your salesforce changes in your sandbox using Sonar.
How Often Should You Refresh Salesforce Sandbox?
Your refresh cycle depends on which version of the Salesforce sandbox you’re using. The versions Salesforce offers are Full, Partial, DevPro, and Dev. Refresh cycles typically range from 1 day to 29 days. For more information on the properties of each type of sandbox, you can check out this Salesforce help article.
You should be updating regularly per the cycles recommended for each sandbox version above, but sometimes you may need to update it sooner than expected.
7 Best Practices for Refreshing Your Salesforce Sandbox
Before beginning the refresh process, ensure your user permission is set to Manage Sandbox. Like most data processes, you have several actions you need to take in a specific order. When it comes to refreshing your sandbox, think of these 7 best practices:
- Choose an appropriate “window”
- Use custom settings and metadata
- Utilize the Sandbox Clone tool
- Create a post-refresh checklist
- Leverage automation activities when possible
- Delete old sandboxes
- Communicate refresh to the organization
Let’s dive into each practice and why they’re necessary for the success of your refresh.
1. Choose an appropriate “window”
Consider the time it will take to complete a refresh so members of your organizations can plan activities accordingly – and avoid rework! The more data your production configuration contains, the longer it will take.
Other factors to consider include the type of sandbox you’re working with and any data that hasn’t been pushed to production yet but should be before the refresh.
You should try to align with Salesforce’s release windows as well. They do these several times per year, and it can throw off your production configuration if you update the wrong version. Beware!
2. Use custom settings and metadata
Instead of hard-coding data into your Apex triggers and workflows, try using a custom setting or metadata that’s easier to modify after refreshing, like an email address field rather than an exact email address of an individual in your organization.
You’ll find custom metadata and settings are much easier to modify in this form as opposed to a very specific email address or data point. That requires inspection and adjustments that are extremely time-consuming and error-prone.
3. Utilize the Sandbox Clone tool
Do you have multiple sandboxes you need to refresh, but need them updated the same way?
By switching your source sandbox in the Sandbox Clone tool, you can simplify your refresh process. Instead of copying your production organization, you’ll copy the Source Sandbox. This makes the process the same for each sandbox and reduces time spent on refresh activities.
4. Create a post-refresh checklist
Documentation is key here. You should always have a documented process for every step to take post-refresh.
Tasks you can include in this checklist are configuring the sandbox, masking sensitive data, updating documents, and reactivating scheduled jobs.
Make sure you review this often and share it with anyone responsible for refreshing the sandbox.
5. Leverage automation activities when possible
You already know refreshing a sandbox can be rather time-consuming and result in errors when done manually.
Avoid long hours and errors through automated processes like using open-source tools. One example is the tool SFDX-Auto DevOps, which automatically backs up all your data and restores it to your sandbox.
Ensure you have the most up-to-date data while reducing hours spent and errors made on refreshes.
6. Delete old sandboxes
Yes, it can be tough to let go of data. Especially when you know you can never get sandbox data configurations back once it’s deleted.
Deleting old sandboxes keeps your Salesforce org clean, frees up space, and reduces the chance of using outdated data.
Be sure to keep clean, updated records so you feel confident deleting your old sandboxes.
7. Communicate refresh to your organization
This may be the last best practice on our list, but it’s equally as important.
Communicating your refresh window to all areas of your organization helps in several ways. For one, this allows all teams to plan their activities accordingly. If admins want to add specific custom fields they need before the next refresh, they know when to do it. If developers have been working on a new project, they know when they need to complete it.
There are so many different scenarios in which this is important, so do your due diligence and spread the word before your next refresh.
Refresh Your Salesforce Sandbox With Confidence
As you’re making changes and refreshing the sandbox, it’s important to fully understand your Salesforce metadata. Successful Ops teams leverage Sonar to reduce click paths and provide a blueprint of every Salesforce object or field so you can quickly implement change and increase team efficiency. You’ll also get to see the before-state of every edit so it’s quick and easy to troubleshoot and resolve unexpected issues.
Learn more about how Sonar helps Salesforce admins with change management.