6 types of Salesforce sandbox plus a clever sandbox strategy

Everyone wants to run tests in a perfectly accurate replica of their production environment. That is, until the one time that replica includes payment information … and they push changes to production and mistakenly bill customers.
‍
Salesforce sandbox management is more complicated than it looks. While Salesforce sandboxes can provide you with a safe space to test ideas, create workflows, and collaborate, they also require forethought to make the best use of them—especially when working across teams and regions.

In this guide, we explore the types of sandbox in Salesforce, how to use them, what to try, and how to avoid the most common errors.

Salesforce sandbox basics

In Salesforce, sandboxes are a paid, add-on feature. They’re duplicate instances of your production environment which include your metadata configurations, code, workflows, and third-party applications, all within a locked container so nothing really goes live and there are no consequences. Sometimes sandboxes include data from your production environment, but that depends on the type of sandbox.
‍
Salesforce offers several grades of sandbox which range from nearly complete—the full sandbox—down to limited environments which are suited for the development of new features, known as Dev Sandboxes. There’s also something called a Scratch Org, which is just a highly configurable version of Salesforce in which to test changes, but thatwhich doesn’t match your instance.
Why might you consider testing in anything other than a full production sandbox? Primarily, speed. All sandboxes are static snapshots of your Salesforce instance, meaning, they’re only updated when you refresh them. Refreshing an even moderately complex Salesforce environment can take days or weeks. For teams practicing Agile, that’s far too long, and that lag means you’re forever testing in not quite the real thing.
‍

‍

The six types of Salesforce sandbox and when to use each

Sandboxes in Salesforce aren’t free, and the number of each type of sandbox you have to work with depends on your license. Generally, you’ll get many copies of the simpler sandboxes like Dev and Dev Pro and just a handful of partial and full ones.
‍
Below, we explore each type in detail—including their Salesforce sandbox refresh rate and storage limits.

‍

Is Salesforce sandbox free?

‍At the time of writing, only the Developer edition sandbox (the lowest tier) is free. All others cost a percentage of your net spend with Salesforce, ranging from 5% (Developer Pro Sandbox) to 30% (Full Sandbox).

‍

1. Full Sandbox—run tests using production data

The Full Sandbox is a complete replica of your production instance which includes all data and metadata. Though, you may not want your exact production data. For example, if you store sensitive data such as customer credit card information or personal data, you’ll want to suppress those records.

Salesforce does offer features to suppress some sensitive data, and it’ll automatically do this with emails by adding the modifier “.invalid” to the end of every email address so you can’t actually send anything. (Though you can override this.) However, there’s a big catch—it only does this with user data, not the actual contacts or other objects where user data is stored. It’s a big unresolved pain point.

The great thing about a full sandbox is that it’s the most accurate sandbox within which to run tests. The data is (mostly) real, which means it’ll likely be messier than dummy data, and thus help you stress test the workflow, discover validation rule corner cases, and load test. It also includes custom objects, AppExchange apps, and workflows as they really exist, so you can understand the real-world impact of updates. By default, it won’t load field tracking (to save on data), though you can change this. Salesforce recommends you create a sandbox template that only loads a specified amount of historical data to speed up refreshes.

The challenge with Full Sandboxes is they can take days or weeks to refresh, and Salesforce throttles how often you can suppress—at the time of writing, you can only do it every 29 days.

Use your Full Sandbox for:

• User acceptance testing (UAT)
• Load testing
• Staging (before you move a change into production)

2. Partial Sandbox—run tests on a frequently refreshed, close-to-accurate instance

A Partial Sandbox is a scaled-down version of a Full Sandbox. It mimics your configuration and metadata, but only a sample of production data, which means that of your hundreds of thousands of customer emails, it will only load thousands of them (limit of 5GB), which nevertheless should be enough to run useful tests. The upside of only loading a sample of data is of course that the sandbox loads much more quickly, and Salesforce allows you to refresh it more frequently—once every five days.

Use your Partial Sandbox for:

• Quality assurance
• Integration testing
• Training

Note: All the same dangers with loading sensitive data in your Full Sandbox exist in your Partial Sandbox—there may be fewer credit card numbers, but they are still credit card numbers.

3. Dev Pro Sandbox—A dev sandbox with more storage

The lowest tier of paid Salesforce sandbox, Dev Pro Sandbox is a scaled-down, faster-loading version of the partial sandbox, of which every administrator gets their own (or multiple) copies. It’ll load your configurations (metadata), but not your data.
‍
The advantage is you have much more data storage than in a dev sandbox, so you can load the sandbox with test data for user training, performance testing, etc.
‍
Use the developer pro sandbox for:

• Isolated testing
• Performance testing
• User training
  

4. Dev Sandbox—Your own playground

The Dev Sandbox is free, and any administrator can create them. It will copy all your metadata but not your data. You also only get 200MB of data storage, which makes it difficult to use for performance testing or big data processing (i.e batch apex, big objects etc).
‍
Use the dev sandbox for:

• Developing code
• Developing brand new features

5. Scratch Org

Technically not a sandbox, Salesforce Scratch Orgs are disposable copies of your source configuration metadata, but without any of the production data. Most organizations get 25 scratch orgs, which expire (or are cleared, rather) every seven days. The intent is that you can use them to quickly test new features, or perhaps do a proof of concept. Once you are done, you can dispose of them. The creation of a scratch org can also be automated via the command line, which makes them a good fit for continuous integration / continuous deployment (CI/CD).

Use the scratch org for:

• Peer review
• Sanity checks
• Proof of concept

6. Salto + Git—unlock the ability to practice Agile and DevOps

The challenge with Sandboxes is they encourage what’s known, somewhat pejoratively, as “ClickOps,” where you pour hours of time clicking through the Salesforce interface, logging into different sandbox environments making changes that are sometimes 10-15 clicks deep. Sandboxes also isolate work, and there’s no great overall view for teams to understand what’s happening where.
‍
Plus, Salesforce sandboxes only work for … Salesforce. Yet Salesforce doesn’t exist in isolation. The average enterprise has 843 business applications, many of which plug into Salesforce with read/write permissions, and testing in an environment that doesn’t at least take at least some of that into account is a sure way to miss something.
‍
Hence the existence of Salto.
‍
Salto extracts all of your org’s configurations and metadata into an interface where you get a full view of everything that’s set up. You can then apply all sorts of DevOps tools, like versioning, which allows you to create unlimited versions of your Salesforce configuration, as well as roll back changes, collaborate, and a whole lot more.