Sandboxes must be regularly refreshed in order to test out the features of the most recent release and avoid undoing development work because it hasn’t been thoroughly tested in a setting similar to your production organisation.
A few things need to be taken into account to guarantee a seamless sandbox setup after the refresh. First and foremost, it is critical to have well-documented procedures in place. Sections like Conga, DocuSign, Data (CPQ/Billing/Advanced Approvals), User Setup, and Integrations should be used to arrange the documentation.
It’s crucial to designate specific people as responsible for particular tasks and to set up backup resources in case the main person is not available. It’s also advised to establish a timeline for the sandbox’s availability.
Even though it is important, not everything can be automated. The lack of thorough documentation will negatively impact the productivity of the team. So, until we reach a fully automated world, maintaining a high availability of sandboxes after a refresh requires us to become proficient in the art of effective documentation.
Step 1: Identify Key Areas and Key People
There could be multiple key owners for your Salesforce instance: people who manage user rights and privacy, people who maintain integrations with services like DocuSign, and people who manage metadata-like data, like CPQ data. You must determine which areas these are and who the important players are in keeping this up to date. It is best to have a backup plan or two in place in case the primary contact is unavailable. This will prevent you from stalling.
Record the necessary steps as well. Make a thorough record of all the steps involved, such as loading CPQ records into a developer instance or setting up system integration.
Step 2: Know Your Sandbox Type
You can use both full and partial sandboxes as well as developer pro sandboxes in many cases, depending on your sandbox strategy. This URL will take you to a list of every kind of sandbox Salesforce offers its users. Each of these sandboxes has a different number and type based on what you have purchased from Salesforce.
Sandbox maintenance varies depending on the kind of sandbox. You might occasionally be refreshing all three kinds of sandboxes simultaneously!
It eliminates the need for hard-coded button IDs, as in the case of DocuSign or Conga buttons, or even in Advanced Approval email templates, 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) and the production (Prod) data goes down. For developer and developer pro sandboxes, on the other hand, you would have to enter the updated sandbox, move all the data, and then copy over the IDs in the references.
Step 3: Obfuscate or Erase Your Customer Data
Make sure that your full or partial data is masking all of your customer data—a process known as sandbox seeding—for compliance purposes, whether it be GDPR or HIPAA. Email addresses, phone numbers, dates of birth, phone numbers, credit card numbers, and social security numbers are all examples of sensitive data.
Although sandboxes are an excellent way to verify that your automation is operating as intended, you won’t get along well if you unintentionally send emails to your clients. There are scripts and tools available on the market that allow you to mask your customer data, including contact and lead information, after a refresh.
In conclusion, ensure that your Email Deliverability in your sandbox is set to System Email only until all of this data has been obscured or removed completely.
Step 4: Remove “.invalid” for Key Users
People asking to be allowed access to the sandbox after a refresh is something I see all the time. To grant access to the sandbox to the great majority of people who do not have this automated in a post-refresh script, keep track of who needs access and methodically remove “.invalid” from their access list.
The most recent feature in the Winter ’24 release addresses this problem. When you refresh, you can designate a public user group that will automatically gain access to the sandbox. This is very time-saving, particularly if you have a big user base that requires access.
Step 5: Load CPQ and Other Packages Data
You require access to all of your data, which functions similarly to metadata, including CPQ records, Conga queries and templates, DocuSign envelope templates, and all of their references, if your refreshed instance is not a full sandbox or partial sandbox. For the functionality to function as it should, all of these records not only need to be recreated, but in some cases, the ID references to the data records in buttons and links also need to be changed.
It is possible to transfer data between instances using programmes like Prodly, Salto, and Gearset. If you don’t have access to these tools, keep track of the data that needs to be moved so that your development team can work on upcoming releases with a refreshed sandbox that contains everything they need.
Summary
Since nobody enjoys losing their work, careful planning and communication are essential to getting everyone on board with a sandbox refresh. More significantly, in order to boost productivity and provide features to business teams as quickly as possible, the downtime required to restore a sandbox after it has been refreshed must be minimised.
Determining what is required, who is in charge, and the steps involved becomes essential to the process. It takes a few refreshes for a big project involving several groups to run smoothly and have the best documentation possible. Thus, you can see how challenging it will be to oversee sandbox refreshes in the absence of a clear procedure.
Leave a Comment