Sandbox Refreshes, The Simple Way

Blog:

This article assumes you have a basic knowledge of Salesforce administration

Sandboxes are a useful tool but can be difficult to manage without automation. Here at Chicago Cloud Group, we follow Salesforce’s best practices for managing development paths. It’s not uncommon for us to have at least one Developer Org where all development starts. When the developer has cleared the changes to be ready for testing, we then migrate it into a full or partial sandbox for user acceptance testing. If everything is working as intended, the changes are then released into Production. All that work and trying out ideas can leave sandboxes a little mangled and messy after a while. That’s where simplifying sandbox creation and refreshes comes in. I will not be covering scratch orgs in this article.

Salesforce provides a handy interface for developers to automatically set up an org for immediately development. SandboxPostCopy when called for the activation step of a sandbox will immediately invoke and begin processing your commands. We internally create Accounts, Contacts, and change custom settings tied to our automation to prevent accidental emails from reaching clients during developer testing.

By convention, we name all our Developer sandboxes with “Dev” in the name to identify them for different rules in this setup. The context.sandboxName() method during the sandbox activation allows you to parse the name given and act on these sort of decisions.

As an extra safety precaution, all logic only runs if the program can determine if it’s running inside a sandbox.

There is a function which disables all the batch classes, reports, and scheduled dashboards from firing as well. This prevents users from being confused by seeing sandbox emails about data which occurred months ago.

Lastly, we manipulate the data to create a base Account where all tests can start from. If the process is running with any data, we are changing the emails on Accounts, Contacts, and Leads. All the batch classes are kicked off in succession. Since batch classes allow up to 5 chained calls, we’re in the clear for having this run on its own.

Once your sandbox class is all set up, the only thing you need to do right before clicking “create” is list the class name in the input field below. It will automatically set up your org for you to your specifications.

The Github repo contains a model of what we use internally. These are extremely helpful in streamlining the development process and reducing overhead cost for enhancements.