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.
How to Supercharge YourDownload the guide ≥
Business Applications with
Software Development Practices
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:
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:
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:
Get more configuration insights in your inbox
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:
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:
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.
Salesforce sandbox development wisdom
So now that you have a grasp on all the Salesforce sandbox options, let’s talk about some wisdom that underpins using them all.
Always be saving prior states: The challenge with Salesforce sandboxes is when you refresh them, you lose the metadata that existed prior. And Scratch Orgs expire each week by design. That means if you want to “back up” your Salesforce Org and revert to a prior configuration if something goes wrong, you either have to export recurring images of your configurations or use a tool like Salto to do this automatically.
Resist the urge to code: Coding Apex is often the fastest workaround to slogging through the Salesforce interface, but it’s almost always a trap. “One-off” code is difficult to maintain and track, and is easy to accidentally overwrite. Apex code should always be viewed as technical debt. You may have to take on some debt to move quickly, but try to avoid it.
Answers to common Salesforce sandbox questions
Do I have to pay for an extra license to AppExchange apps used in Sandbox? Generally, no. Most apps have what’s known as an open site license, though the sandbox version may be missing some features. (The exception: Some AppExchange applications are pay-per-use, and using them in the sandbox may count against your limit.)
What is the refresh interval in Salesforce sandboxes? It depends on the sandbox. You can refresh Dev and Dev Pro Sandboxes every one day, Partial Sandboxes every five days, and Full Sandboxes every 29 days, and Salto sandboxes whenever you like.
How much configuration data can my Salesforce sandbox load? It depends on the sandbox. Dev can load 200MB, Dev Pro can load 1GB, Partial can load 5GB, and Full can load all your data (though you probably don’t want to do this—it could include massive amounts of useless Chatter data.)
Getting started with Salesforce Sandboxes
Salesforce Sandboxes are highly useful testing environments that can help you avoid errors and polish changes before they go into production. But they do have some limitations, and to fully rotate to practicing Agile and DevOps for Salesforce, you’ll want to investigate a tool like Salto which can give you far more functionality, and the power to collaborate across the business.