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.

Provided by Salesforce.com @ (https://trailhead.salesforce.com/en/content/learn/modules/declarative-change-set-development/plan-for-changes-to-your-org)

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.

Recent Posts

“What can I say about Virtuoso other than wow! Their Salesforce experience, expertise, and guidance have given our company a customized platform that puts us head and shoulders above our competition. It is no stretch to say Virtuoso truly transformed our business. When we started, our staff was running our business on spreadsheets, pad and […]

Read More
Customized Salesforce to our Business Needs

“With the help of Virtuoso, we have been able to customize Salesforce to our business needs. The knowledge and programming skills they have brought us have allowed us to continue work as usual. Virtuoso is setting us up with the resources we need to have continued success with Salesforce. Their team brings a sense of […]

Read More
They are Part of Your Team

“We have and continue to have the pleasure of working with the Virtuoso team for our ‘CRM Journey.’  Their team has patiently worked with our team to customize a platform that fits our business process and workflow while providing us continuity and continued consulting to align with new and different sales projects.  Wearing many hats […]

Read More
1 2 3 30
© 2024 Virtuoso Chicago, LLC.
Privacy Policy
A member of the SMG3 family
smg3.com
cross-circle