Salesforce sandboxes vs. scratch orgs: which environment should you use?

Sandboxes and scratch orgs are both essential tools in the Salesforce developer’s toolbox and are fundamental to the effective implementation of a Salesforce DevOps process. At first glance, they may seem interchangeable — after all, they both provide development and testing environments. But when you dig into the details, there are some notable differences between sandboxes and scratch orgs in terms of use cases, capabilities, and overall approach. In this post, we’ll explore everything you need to know to choose the right tool for your needs.

Sandboxes: your production clone

Sandboxes have been a cornerstone of the Salesforce development process since the early days of the platform.

Sandboxes come packed with all of your actual production metadata, configurations, and sometimes data. Having this full replica makes sandboxes invaluable for thoroughly testing changes before deploying to production, as part of user acceptance testing (UAT). Developers can experiment freely without worrying about disrupting real users and processes.

The various types of sandbox available allow you to balance accuracy with practicality, but your ability to create these sandboxes will vary depending on the Salesforce edition you’re using, with some types only being available to Unlimited or Performance edition Salesforce orgs.

• Full copy sandboxes are faithfully reproduced production environments containing the full data and metadata set from your production org. They give you the highest fidelity for user testing, training simulations, and replicating issues. But all that data takes time to copy and resources to maintain.
• Partial copy sandboxes strike a balance by including your metadata and a sampled subset of production data. You still get solid test coverage without as much overhead. As a testing environment, the advantage over your full copy sandbox is that you can refresh a partial sandbox every 5 days, versus every 29 days for a full copy.
• Developer sandboxes provide a barebones configuration-only option. You get 100% accuracy on all your metadata, validation rules, and other customizations without any live data. This allows for rapid environment creation and iteration during early development cycles.
• Developer Pro sandboxes start with the developer template but give you additional storage for more complex projects.

The persistence of sandboxes is a double-edged sword. Having environments that stick around indefinitely allows you to install multiple code versions for upgrade testing or troubleshoot legacy issues. They’re also much easier to align with a branching strategy that relies on a branch-to-sandbox mirroring approach.

But over time, sandboxes can also become cluttered with stale configurations and unused components. It’s important to plan your sandbox refresh cycles well to make sure you have up-to-date environments that accurately reflect your Salesforce org — and to make sure the rest of the team know the sandbox will be out of action until the refresh is finished.

Overall, sandboxes shine when you need high-fidelity test environments or ongoing access to production replicas. But that fidelity comes at the cost of agility.

Scratch orgs: built for speed

As Salesforce has embraced agile and continuous delivery, scratch orgs have emerged as the environment of choice for rapid development workflows. Scratch orgs give you configurable blank slates, derived from an enabled DevHub. This creates a limitation: you can only spin up scratch orgs from a production org, not from sandboxes.

Scratch orgs are entirely disposable, with a maximum lifespan of 30 days. This forces developers to stay focused on incremental progress rather than accumulating technical debt. Since scratch orgs disappear frequently, you must capture all your changes in source control. This makes your version control system the single source of truth.

Scratch orgs can be created dynamically from your Salesforce development environment, via the Salesforce CLI. They adopt the Salesforce DX conventions for structuring your metadata into folders. While it’s theoretically possible for multiple developers to share a scratch org in a similar way to a sandbox, in practice this is rare given the ability for each developer to spin up a new scratch org quickly and on demand.

Configuring scratch orgs is declarative using JSON definition files. You can pre-define features, policies, and sample data templates needed for each project in these configurable files. Spinning up scratch orgs then becomes a simple and repeatable task. Say your team wants to work on a new campaign management feature. Simply initialize a scratch org from a definition that includes the campaign object, associated rules, and test campaigns.

Scratch orgs have limits — which are very intentional for the type of use case for which they’re designed. Much like sandboxes, the number of scratch orgs you’re able to have active at the same time will vary depending on the Salesforce edition you have available. The maximum lifetime of a scratch org is 30 days, after which all work is deleted along with the org. Also keep in mind that a scratch org can only hold up to 200MB of records and 50MB of files.

This combination of ephemeral lifecycles and configurable specs allows scratch orgs to excel at speed and agility. They align perfectly with continuous integration and delivery (CI/CD) workflows, as well as performance testing. Automation can rapidly spin up tailored orgs on demand for development, execute deployment and testing, then dispose of the resources. No need to worry about cleaning up — just start fresh with each set of changes.

Of course, the short-lived nature of scratch orgs also comes with tradeoffs. Transient test environments make long-term troubleshooting and regression testing more difficult. And generating disposable test data isn’t always viable for complex scenarios.

Head to head: sandboxes vs. scratch orgs

Now that we’ve explored sandboxes and scratch orgs individually, how do you choose between them? Here are some key considerations:

• Test data needs. Sandboxes are ideal if high-fidelity production data is needed for UAT, training, or troubleshooting. But scratch orgs work well with generated test data.
• Release processes. Scratch orgs align better with agile teams doing continuous builds and delivery. Sandboxes allow for more traditional project development workflows.
• Customizability. Scratch orgs enable configurability for each feature branch. Sandboxes provide consistency with production.
• Environment control. Scratch orgs encourage starting fresh regularly. Sandboxes can accumulate unused configurations over time.
• Cost considerations. Scratch orgs don’t consume licenses like sandboxes. But sandboxes offer more compute resources.

The right choice depends heavily on your use cases and development best practices. Often a combination of both sandbox and scratch org strategies is best. Many teams develop new features in scratch orgs, then conduct final integration, testing, and training in a sandbox pre-production.

Strike the right balance

Sandboxes and scratch orgs can empower developers to innovate safely on the Salesforce platform. But their strengths and weaknesses should be considered when deciding which one to use.

As you design your development workflows, carefully consider test data needs, release cycles, cost, and team preferences. With the right balance of sandboxes and scratch orgs, you can maximize productivity, minimize risk, and deliver user value rapidly and continuously. Book a consultation for help getting started.

However you choose to use sandboxes and scratch orgs, Gearset has you covered, across any Salesforce environment, so you can build, test, and deploy with confidence. Learn more by downloading our Salesforce DX whitepaper.