Advanced Sandbox Concepts for Salesforce Admins

Salesforce Sandboxes make up a core component of Salesforce development. The golden rule is to develop in a sandbox environment first before changing your live system. This is to ensure that everything works as expected, and that you don’t negatively impact users.

This article will build upon the fundamentals learnt from What Is a Salesforce Sandbox? and introduce additional concepts that every admin should be aware of.

Key Concepts

Whether you are developing something completely new or adjusting something that already exists, it’s important to do this in a way that doesn’t interrupt live users or customers.

Be sure to check out this article to help grasp the concepts Data Masking, Data Seeding, and Email Deliverability.

Sandbox Clone

Imagine you are due to refresh your sandboxes but not everything has been deployed to production yet. Instead of losing what you’ve developed, you can clone an existing sandbox to back up what’s within. This way you can refresh your development pipeline without losing all your hard work!

Something to note here is that you can only clone sandboxes using the same type, and this copies metadata and data as part of the process.

Preview vs. Non-Preview Sandboxes

Something else that becomes particularly useful around the time of each Salesforce release is Sandbox Preview.

If you refresh your sandbox within a preview window, it will be upgraded to the newest Salesforce release first, so you can test any customizations before the release hits your production org.

DevOps

Salesforce DevOps is an abbreviation for Development Operations. It’s an approach to bring Salesforce Admins, Developers, and Architects together to deploy and test changes in the most efficient way possible.

DevOps principles are common across different systems. As such, you may have come across this in other systems such as Amazon AWS or Microsoft Azure.

Depending on where you look online, you may see some variation of the steps involved in the DevOps process. In a Salesforce context, the high-level steps are as follows:

1. Plan
2. Create
3. Test
4. Release
5. Observe

While this example is based on Salesforce provided tools that help, the landscape of your process may vary if you have partner products that perform some of these functions (Gearset, Copado, Provar, Flosum, etc.)

As a Salesforce Admin, it’s important to know the principles behind DevOps so that you can effectively work together with the team to deploy, test, and release changes in a more robust fashion.

Match Production Licenses

You may sometimes provision additional Salesforce products or features. When this happens the new licenses will be added into your production org.

If you want to add the licenses to your sandbox org you can match production licenses without having to refresh the environment and potentially lose any undeployed changes.

Sandbox Expiry

Salesforce sandboxes have a limited shelf life. If an environment has not been used for 180 days, it’s considered inactive and will be deleted by Salesforce.

Salesforce will send alerts at 90, 120, and 150 days of inactivity. This alert will include details of the sandbox in question.

These alerts are sent to those with the Manage Sandbox Permission in the production org (unless you’ve disabled the alerts for the entire org). To stop your sandboxes being deleted, simply ensure you log in at least once every 179 days!

Programmatic Sandbox Management

The majority of Salesforce Admins will be used to managing sandboxes from the Setup Menu of a production org. From here you can perform common functions including creating, deleting, cloning, and refreshing sandboxes.

For those of you who are used to developer-type tools, you can also use the Salesforce CLI to manage your sandboxes, with dedicated commands to Create, Clone, or Delete a sandbox.

You can also use the Tooling API to achieve the same functions including Sandbox Creation, Clone, Refresh, and Delete.

I now have some hands-on experience with these functionalities; you can see me demonstrating how to Create, Clone, and Delete a sandbox in the video below:

Summary

Sandboxes are a powerful tool and it’s best practice to develop all changes in a sandbox before deploying the changes onwards to production. When you come to deploying from sandboxes, be sure to review Special Behavior in Deployments to avoid being caught out!

In this article, I’ve provided highlights from a whistle-stop tour of Advanced Sandbox Concepts. Full content on Salesforce Sandboxes can be found here on Salesforce Help.

I’d love to know what has and hasn’t worked for your organizations when using Sandboxes, feel free to share your own experiences in the comments below!

Other Resources

• Sandbox Cloning (Salesforce Help)
• What are Preview and Non-Preview Sandboxes? (Salesforce Help)
• A DevOps Guide to the Salesforce Platform (Salesforce Admins)
• Sandbox Licenses and Storage Limits by Type (Salesforce Help)
• Inactive Sandbox Expiration (Salesforce Help)