Salesforce Sandboxes Best Practices: Explore Use Cases

Let’s start with the basics — Salesforce sandboxes are separate, isolated environments that mimic your Salesforce production instance. They are used by admins and developers to build and test new features that have been requested from end-users within your organization. Organizations use sandboxes to protect production environments from defects and bugs. The #1 Salesforce sandbox best practice is that YOU SHOULD 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 can increase the productivity and efficiency 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 different types of sandboxes, and each has a specific purpose. The Salesforce edition purchased by your organization determines the number of each kind of sandbox supplied.

The table below summarizes the differences between each type of sandbox in detail.

*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 the deployment of bugs. 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 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; sandboxes have multiple uses with a variety of perks for each.

Scratch orgs and dev sandboxes

Scratch orgs and dev sandboxes are perfect for coding, whether you are using the Salesforce interface to create features, writing elaborate code through an IDE, or 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 — 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 confirming 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 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 involves 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 routine? 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. Tests can run in a full sandbox to instill confidence in the code, and the users, that it will work in live scenarios.

Key takeaways

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.

Druva’s Salesforce sandbox seeding solution

Druva helps organizations accelerate cloud projects and drive efficiency with predictable sandbox seeding. This enables faster testing with greater confidence via self-service data delivery, reducing time and costs to prepare sandboxes. This means there is no need for managing spreadsheets or data loaders.

Druva provides real-time, on-demand test data that reduces project costs, requires less resources, and shortens project schedules. What used to be a manual process that could take hours or days can now be automated and completed in minutes.

Download our datasheet on Salesforce Sandbox seeding to see how Druva can help you eliminate the repetitive tasks needed to create reliable test data, and achieve significant cost savings up to 10-20X compared to full sandboxes.