Imagine that you are the sole consultant working on a project with XYZ company and you are about to go on a two week vacation to Porto Carras. You are in a good mood due to your upcoming travel; the project is on track. You send a project update to the XYZ Admin about the configuration you completed in their sandbox and remind him that you are out of the office for the next two weeks.
Two weeks go by very fast. The long walks and the tranquil evenings sipping Melissanthi, or whatever it is you like to drink, has made you feel refreshed. Now back to reality!
You log into the XYZ org only to find that the sandbox is refreshed. Your eyes bulge out and you break into a sweat trying to gauge the situation. You double check and triple check that you logged into the right instance. So while you were out and having a great time, your XYZ Admin decides to be proactive and refreshes the sandbox. All of your configuration work goes down the drain along with your project timeline and budget.
Incidents like the above come with a cost either to you or your client. Other nightmare scenarios that come to mind are multiple developers overwriting each other’s work, or multiple vendors configuring their app in the same sandbox.
Large organizations may have release managers and processes in place for development, testing and deploying their releases in different environments. They might have best practices for Sandbox management. However most nonprofits have limited staff and they cannot afford to have a dedicated release manager on their payroll – but that doesn’t mean that they shouldn’t follow the best practices of Sandbox management.
Sandboxes
Sandboxes are copies of your production environment; the changes you make in your sandbox don’t affect your production environment. Different types are available depending on their intended use. How do you decide which one to get? Choose the one that serves your purpose and budget. In my opinion, you should have at least one sandbox for development and another one for staging.
Sandbox Types:
- Developer: A Developer sandbox (not to be confused with Developer Edition orgs) copies only the configuration and not your production data. This is mainly used for coding and testing. Any test data required for testing can be uploaded using a data loader or a similar tool. You get only 200 MB of data storage and you can refresh the sandbox once a day.
- Developer Pro: The Developer Pro sandbox is similar to the Developer sandbox but with 1 GB of Data storage.
- Partial Copy: Partial Copy copies your configuration as well as a sample of your data as defined by a sandbox template. You have 5 GB of Data Storage and the refresh interval is 5 days. These are used for testing and training purposes.
- Full: Full sandboxes contain all your production configuration and data. You can refresh it only once every 29 days. These are usually best for production debugging and staging.
What happens when you refresh a sandbox?
When you refresh a sandbox, it goes into a queue and it can take anywhere from a day to a week or more. I remember refreshing a full sandbox the very first time – it took 6 days for it to be ready! So make sure to account for refresh time in your project plan. When you refresh, Salesforce replaces the current one with a fresh copy of your production org. The refreshed copy is in inactive state and you have to activate it.
What steps can you take for managing your sandboxes and deploying changes from org to another? Here are some tips for you to follow:
- Plan which sandboxes you’ll use and your refresh timeline for each, at the project onset. Do you need one developer sandbox or multiple ones? Do you need a full copy or will a partial copy suffice your needs?
- Document your environments and what steps are needed after sandbox refresh.
- Decide on who should be refreshing the sandboxes.
- Plan which sandboxes will need test data and use the same test data across each of the dev sandboxes.
- Ensure that sensitive data is not loaded into the sandbox.
- Plan your deployment between environments. How will you deploy changes from one org to another? What tools are you going to use? Are there any post deployment steps to configure? If you are fixing UAT issues, are you fixing them directly in UAT sandbox or are you fixing them in dev sandbox and then pushing the changes to UAT? Have a process in place or else you’ll reintroduce the issues.
- Create user templates in production. If you do not have additional licenses, deactivate users who won’t be logging and testing in the sandbox and instead assign these licenses to developers.
- Keep the Salesforce releases in mind and ensure that your release is not affected.
To learn more about Sandboxes, check out this Salesforce Trailhead
You might be interested in these posts as well:
