Salesforce Sandbox Refresh Best Practices

Sandbox Refresh Best Practices

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.

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.

production and sandboxes

Different Types of Salesforce Sandboxes

Salesforce offers 4 types of sandboxes:

  1. Developer Sandbox 
  2. Developer Pro Sandbox
  3. Partial Data Sandbox
  4. 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
Types of Salesforce sandboxes
Types of Salesforce 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:

  1. Pre-actions, which take place before the refresh button clicks.
  2. Refreshing actions, which take place between the refresh button clicks and the sandbox is ready.
  3. Post-actions, which take place after the refresh is completed.
sandbox refresh actions
sandbox refresh actions

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:

  1. Define what objects and fields to mask
  2. 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.

Salesforce Integration Diagram
Sample Salesforce Integration Diagram

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:

  1. 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.
  2. 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.
auto run apex
Auto run apex

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.

One Response

  1. Xi Xiao 2020-04-17

Leave a Reply