How many Salesforce sandbox instances should you have? What is each of their purposes? What are their inputs and outputs? When do you migrate from one to another?
At the absolute minimum, there should be one sandbox for development and testing. It’s too risky to make changes directly in production. Unless, the data that needs to be changed is only in production (such as updating the wording of an email template).
At the other end of the spectrum, you should have 5 sandboxes:
- Scratch orgs are great for developing a single user story. Developers build and unit test, then move the work to Dev.
- Dev is the main development org with all user stories. You own this sandbox. At the end of each sprint, work should be moved to QA/SIT.
- QA/SIT is owned and used by the client to test all your work. Sprint demos are performed here. In addition, the SIT part (System Integration Testing) means non-production external systems are connected to perform integration testing. As you prepare for go-live, work is promoted to Training and UAT.
- Training provides a stable environment for trainers to teach users how to use the work you’ve developed. It’s managed by the training team and holds experimental data (e.g. “John Doe”).
- UAT is for User Acceptance Testing. This means it should behave identical to what the client will receive when in Production. Migrated data is also verified. Aside from bogus email addresses (“.invalid”), data should be accurate. When you receive the client’s sign-off, work is promoted to Production.
The takeaway
This diagram is meant to be a starting point. Depending on the complexity of your client and the project, you may need to either include additional sandboxes or remove some.
Category:
Salesforce