Let’s start with the basics. Salesforce sandboxes are separate, isolated environments that mimic your Production instance. They are used by admins and developers to build and test new features requested from end-users. We use sandboxes to protect our Production from defects and bugs. The #1 rule is WE NEVER DEVELOP IN PRODUCTION!

Sandboxes provide strategic benefits to your Salesforce development process. Using sandboxes reduces operational risk in terms of downtime in Production. They increase the productivity and efficiencies of admins and developers by catching issues earlier in the development process when code is easier and less costly to fix. Salesforce provides customers with multiple types of sandboxes, and each has a specific purpose. The Salesforce edition purchased determines the number of each kind of the sandbox supplied.

The table below summarizes all you need to know about each type of sandbox.

*When refreshing a sandbox, it starts by placing the request inside the queue, which is shared by multiple Salesforce customers that reside on the same Salesforce instance (server). The refresh could be done that day, or it could take a week. It all depends on the line in the queue. There is no insurance you will get it that day and no way to jump in front of the line.

**The main problem with Partial Sandboxes is the unreliability of the data. The sandbox is limited to 10,000 records per object, and parent-child relationships are not maintained. Orphan records make it harder to perform accurate tests and could lead to bugs getting deployed. The data provided by Salesforce in a Partial sandbox isn’t dependable for testing.

Sandbox Use Cases

Each type of sandbox serves a specific purpose. Connecting these sandboxes creates your path to Production or what is called your Software Development Lifecycle (SDLC). There is no standard, or one size fits all SDLC. It is all dependent on the size of your team and how many projects/user stories are running simultaneously. But using each sandbox for their designed purpose will increase efficiency and shorten development cycles.

Here is a breakdown of sandbox types and their best use cases.

Most sandboxes can have multiple use cases, but each one shines for a particular reason.

Scratch Orgs & Dev Sandboxes

Scratch Orgs and Dev sandboxes are perfect for coding, whether you are using the Salesforce interface to create features or writing elaborate code through an IDE, and the first round of testing (unit testing). We recommend a personal sandbox given to each admin or developer at the beginning of any project or sprint. Private sandboxes provide team members with the freedom to create their functionality without interfering with others’ code. This setup helps to improve efficiency and productivity if and when you implement Agile and DevOps processes.

Unit testing is exactly what it suggests. It is testing the individual components or modules of code. Its purpose is to validate that each element is performing as designed. Unit testing typically has one to a few inputs seeking a single output. These limited scenarios require a small subset of data, which is ideal for scratch orgs and dev sandboxes. It isn’t necessary to have a large number of records or data from every object. You only need a small subset of data from objects associated with a particular component.

Dev Pro Sandboxes

Dev Pro Sandboxes are ideal for integration and QA testing. Integration testing is the joining of multiple separate modules, and confirm they work in harmony. This testing will have more inputs and outputs, requiring more data from more objects. The additional data storage of Dev Pro sandboxes provides an excellent environment for integration testing.

Dev Pro sandboxes are suitable for QA testing as well. We recommend having individual sandboxes for each QA member if it is possible. QA testing involves many scenarios across several objects. QA members will require a subset of data across most or all objects to do adequate testing. The extra storage provides enough space for ample test data but puts a limit to prevent wasting time loading unnecessary data.

A third use case for Dev Pro sandboxes is training. Typical training revolves around particular scenarios with a specific data set. Overall, any situation that tests several modules but doesn’t demand an overwhelming amount of data should use a Dev Pro sandbox.

Partial Sandboxes

The next stage in release management is User Acceptance Testing (UAT). UAT is an essential type of testing and can’t be overlooked or skipped. UAT is the end-users’ first chance to put their hands on the app and run it through real-life scenarios. Were all requirements met? Does it fit into my day-to-day life? UAT can’t start until the app is mainly feature-complete. Users will run through a set of test cases to test every feature of the app. A Partial sandbox can hold a sufficient amount of data to test all scenarios and requirements of UAT. But remember, you can’t rely on the data provided by Salesforce, as most records are random and unrelated.

Full Sandboxes

The final step before deployment is staging and performance testing. Only a Full sandbox can support staging and performance testing, as these tests require a production-like environment. A Full sandbox can hold all the data inside Production, including attachments and content documents.

Staging gives dev teams the ability to test their deployment and catch all errors before implementation to Production. Performance testing runs the app through its paces and makes sure it can handle the data size of your production instance. Users get frustrated when features run slowly under the weight of thousands of records. These tests are run in a Full sandbox to instill confidence in the code and the users that it will work in live scenarios.

Conclusion

Salesforce provides every customer with sandboxes for customizing their org to meet users’ needs. There is no excuse for having to make changes in Production. Your release management process will dictate the purpose of each sandbox and how many will be used. And remember to refresh all sandboxes after deployment to guarantee code mimics production.