One day I sit in the office and wonder what are the Salesforce sandbox refresh best practices, does a Salesforce sandbox refresh checklist exist? I google-searched, but couldn’t get a good answer. So I spent time on this topic and combined all the points you need when refreshing a Salesforce sandbox.
In this article, I describe both basic concepts (what is Salesforce sandbox, what types of Salesforce sandboxes exist) and the Salesforce Sandbox Refresh Best Practices.
Feel free to use the table of content below to jump straight to any section as you need.
Table of Contents
What is the Salesforce Sandbox
Salesforce sandbox is the test environment for your Salesforce Production organization (or org for short). You can create different types of sandboxes, or different copies of the same type to fulfill different purposes, such as development, integration test, training, or User Acceptance Test(UAT).
The Sandbox environment is totally isolated from the production org. You can test as you want without affecting the production org.
Different Types of Salesforce Sandboxes
Salesforce offers 4 types of sandboxes:
- Developer Sandbox
- Developer Pro Sandbox
- Partial Data Sandbox
- Full Sandbox
You can view your sandbox information by following these steps:
- Log into production org with an admin user
- Go to Setup
- Type Sandboxes in the Quick Find box, then select Sandboxes
Developer Sandbox
Developer sandbox replicates production org metadata without user data. The metadata includes:
- Configuration
- Apex
- All users
The developer sandbox has only 200MB space. It’s suitable for individual development, but can’t accommodate a large volume of datasets.
Developer Pro Sandbox
Developer pro sandbox includes the same metadata as the developer sandbox.
However, developer pro sandbox has a larger space, 1GB limitation. So it is suitable for development requiring interaction with user data, or integration tests.
Partial Copy Sandbox
Partial copy sandbox includes:
- the same metadata as the developer sandbox
- a sample of the production org data defined by a sandbox template
Partial copy sandbox is suitable for the integration tests, user training, or UAT.
Full Copy Sandbox
Full copy sandbox replicates the production org. It contains both metadata and user data.
Full copy sandbox is a full-fledged copy of the production org. It is suitable for UAT.
Salesforce Sandbox Refresh Best Practices
We use the full copy sandbox as an example to go through the Salesforce sandbox refresh best practices. If you are refreshing another type of sandbox, pick only subsets or adjust according to your needs.
According to the timeline, we divide all points of the checklist into three categories:
- Pre-actions, which take place before the refresh button clicks.
- Refreshing actions, which take place between the refresh button clicks and the sandbox is ready.
- Post-actions, which take place after the refresh is completed.
Pre-actions
Document Sandbox Configurations
Document all sandbox configurations that need to be updated after the refresh. Once the refresh is completed, all current sandbox configurations are lost. So it is important to compile them into a document so we can revert after the refresh is done.
You need to take these points into your Salesforce sandbox refresh checklist, including:
- Scheduled jobs
- Deliverability
- Named Credentials
- Custom Settings
- Custom Metadata Types
- Remote Site Settings
- Managed package configurations
- Connected Apps
- Apex Exception Email
- Hardcoded values both in Apex and declarative tools
- User credentials used in the integrations
- Salesforce apps and their configurations
Take your time to compare these configurations between the sandbox and the production org. Write down the ones with different values and figure out why they are different. When you create this Salesforce sandbox refresh checklist document, using screenshots sparingly is a good idea.
Define Sensitive Data
Salesforce is a CRM system that contains sensitive customer data. Full sandbox inherits all sensitive data from the production org.
So we must take action to mask these sensitive data. Action points are:
- Define what objects and fields to mask
- Decide how to mask the data
Typical sensitive objects are account and contact.
Typical sensitive fields are name, phone number, mailing address, and birthday.
Salesforce provides a paid data masking tool. You can use the Trailhead module to see if it fits you. Alternatively, you can create a tool of your own, for example, a data masking Apex function to run in the batch context.
Document Existing Integrations
It is common that the Salesforce environment has integration channels with other systems, such as SAP, Microsoft Office 365.
You need to have an up-to-date integration diagram to answer questions like:
- What are the integration channels in place?
- What are the credentials used?
- Is the Connected App used?
- Which Salesforce API is used?
- How would two-side teams collaborate in the entire refreshing time period?
- How to switch the integration endpoint from production to test environment?
The last question is the most critical one. It is the bottom line – make sure you do NOT screw production data, i.e. send Salesforce sandbox data into the integrated system production environment.
A sample integration diagram looks like the picture below.
Refreshing Actions
Refreshing actions are the ones to take between the sandbox refresh button clicking and the sandbox is ready. This phase is easily forgotten, but important in Salesforce Sandbox Refresh Best Practices.
Depending on the size and complexity of the Salesforce production org, full copy sandbox refresh takes from several days up to 1+ week to finish.
During this time, the refreshing sandbox is not accessible, but you can take actions outside of the sandbox, such as preparing the integration system.
Post-actions
Post-actions are the actions to take after the sandbox is ready. Most of the reconfiguration of Salesforce Sandbox Refresh Best Practices is done in this phase.
Configure the Sandbox
If you are new to the sandbox refresh, I’d recommend the manual way. Once you are more familiar, you can gradually move to a semi-automated way.
First, we describe the manual way. Log into the sandbox with a system admin user. Then execute all steps documented in the Document Sandbox Configurations section of the pre-actions category.
Then, the semi-automated way can save your time. It includes two ideas:
- The sandbox can automatically run an Apex file when the refresh is done. You can use this Apex to create data records, run batch jobs, or anything Apex supports.
- You can create a batch script to invoke the Salesforce CLI to update the metadata, like Named Credentials, Custom Settings, Custom Metadata Types, in the sandbox environment.
Mask Sensitive Data
Whether you decide to use a Salesforce data masking tool or create your own tailored tool, it’s the time to execute and mask user sensitive data.
Depends on the volume of data, deactivating triggers or/and declarative tools (Process Builders and Flows) can reduce the total execution time.
Re-establish the Integrations
Now it’s the time to take action to resume the sandbox integrations. Make sure the endpoint URLs, credentials, etc. are all updated. These values are typically saved in the Custom Settings, Custom Metadata Types, and Named Credentials.
Test the connections work as expected.
Reactivate Scheduled Jobs
All scheduled jobs are deactivated after the refresh. Activate the ones needed to run in the sandbox.
Test and Update the Documents
Now it’s time to test everything end-to-end in the sandbox.
Make sure you also have added things you have learned during the refresh period into your documents. This avoids hassles for the sandbox refresh next time!
Conclusion
As you see, the Salesforce full sandbox refresh is a time and energy taking task. Moreover, there is no single Salesforce sandbox refresh checklist fitting all. A lot of planning, exploration, communication, and collaboration are required. But if you treat it carefully you gain invaluable benefits, such as:
- a close-to-production full copy sandbox
- teams with excellent Salesforce technical capability
- up-to-date technical documentation and integration diagram
That’s all I’d like to share with you about Salesforce Sandbox Refresh Best Practices. You might also wanna check other posts on this site.
If you see some action points are missing, please leave comments below, I will keep this article up-to-date. If you have a question, don’t hesitate to ask. I will answer as many and as soon as possible.
Hope you enjoy this post!
Hi,
My addition would be to use Branding to seperate the different orgs from one another. One can do so by adapting the colours.
Cheers
Hello,
Thank you, i want to know if we have some fonctionnaly in sandbox but this fonctionnlity is not deployed in prod, we can lost this fonctionnality with refresh?
Cheers
Yes, you do. Refresh will lose things in the current environment. So do it with care.
Hi Xi, thank you for this great article! You mentioned the semi-automated way to configure the sandbox post-refresh. Have you tried this approach? Could you talk more about the Apex file and maybe share an example if you don’t mind? I’m very new to Apex and don’t have an idea of how the file should be written. Thanks so much again!
This was so helpful! Thank you for this article.
Very Helpfull, thank you so much !
You forgot about the Experience builder (Ex Communities) Activation, After refresh