Regularly refreshing sandboxes is crucial to try out the latest release’s features and to prevent rolling back development work due to a lack of testing in an environment akin to your production org.
To ensure a smooth sandbox setup post-refresh, several factors need consideration. Firstly, having well-documented procedures in place is essential. Documentation should be organized into sections such as Conga, DocuSign, Data (CPQ/Billing/Advanced Approvals), User Setup, and Integrations.
Additionally, it is important to assign specific individuals accountable for tasks and establish backup resources for situations when the primary person is unavailable. Furthermore, setting a timeline expectation for sandbox availability is recommended.
While automation plays a significant role, not everything can be automated. In the absence of comprehensive documentation, team productivity will suffer. Thus, mastering the art of effective documentation is essential to making sure we have a high availability of sandboxes post-refresh until we reach a fully automated world.
Step 1: Identify Key Areas and Key People
Your Salesforce instance may have several key owners – like folks who maintain integrations with tools like DocuSign, folks who are in charge of data privacy and user management, and those who maintain data which are like metadata, such as CPQ data. You need to identify what these areas are and who are the key people involved in maintaining this. You don’t want to stall, so always find a backup person or two to stand in in case the main person is out of the office.
Also, document what steps are necessary. Let’s say you have CPQ records to be loaded in a developer instance or the integration between systems that need to be set up – make a detailed note of all those steps.
Step 2: Know Your Sandbox Type
In a lot of instances, depending on your sandbox strategy, you may use full and partial sandboxes and then developer pro sandboxes as well. Here’s the link to all the available types of sandboxes that Salesforce provides its customers. The number and the type of each of these sandboxes are dependent on what you have purchased from Salesforce.
The amount of effort to refresh sandboxes depends on the type of sandbox. In some instances, you may be refreshing all three types of sandboxes at the same time!
For example, if it’s a full or partial sandbox (for partial, you can define what object records you want to copy when refreshing in the template), since the production (Prod) data comes down, you don’t have to worry about hard-coded button IDs, such as in the case of DocuSign or Conga buttons or even in Advanced Approval email templates. However, in the case of developer and developer pro sandboxes, you’d need to go into the refreshed sandbox and then move all the data and then copy over the IDs in the references.
Note: This can be automated using scripts and sophisticated tools, but not everyone has that luxury.
Step 3: Obfuscate or Erase Your Customer Data
For compliance reasons, whether it’s GDPR or HIPAA, make sure that your full or partial data is masking all of your customer data, known as sandbox seeding. Sensitive data can be anything from emails, date of birth, addresses, and phone numbers to credit card and social security numbers.
While sandboxes are great to test if your automation is working correctly, inadvertently sending emails to your customers is not going to be looked at so kindly. There are tools in the market and scripts that can be written so that post refresh, your customer data on lead, contact and any other customer data can be masked.
Finally, in your sandbox, until you have all this data obfuscated or erased altogether, make sure to set your Email Deliverability to System Email only.
Step 4: Remove “.invalid” for Key Users
One of the things I notice on a constant basis is users requesting to get access to the sandbox post refresh. For the vast majority of those who do not have this automated in a post-refresh script, maintain a list of who needs access and systematically remove “.invalid” to provide them access to the sandbox.
There is a latest feature in the Winter ‘24 release that helps with this issue. You can specify a public group of users at the time of refresh who will automatically get access to the sandbox upon refresh. This saves a lot of time, especially if you have a large group of users who need access.
Step 5: Load CPQ and Other Packages Data
If your refreshed instance is not full sandbox or partial, you need access to all your data, which behaves like metadata – like CPQ records, Conga queries and templates, DocuSign envelope templates and all their references. All these records not only need to be recreated, but in some instances, you’d need to change the IDs references the data records in buttons and links for the functionality to work the way it always should.
Tools like Prodly, Salto, and Gearset can be used to move data from one instance to another. Those who don’t have these tools available at their disposal, maintain a list of data that needs to be moved for the refreshed sandbox to have everything your development team needs to work on future releases.
Careful planning and communication are key to ensuring everyone’s on board with a sandbox refresh, as nobody likes to lose their work. More importantly, the downtime to bring back a sandbox after it has been refreshed has to be as low as possible to increase productivity and get features out to business teams as soon as possible.
Identifying what is needed, the people responsible, and the steps involved becomes a pivotal part of the process. For a large project with multiple groups involved, it takes a few refreshes to function like a well-oiled machine with the most thorough documentation. So, you can imagine how difficult it will be to manage sandbox refreshes if you don’t have a well-defined process.