A Salesforce sandbox is a copy of your production org where you can build, test and train without touching live users or data. Every sandbox copies your production metadata (configuration and code); only Partial Copy and Full sandboxes also copy data. There are four types, and they differ in data storage and how often they can be refreshed.
This guide was first published in 2020 as "What Is Sandbox In Salesforce?". It has been rewritten for 2026: the four types side by side, which one fits which job, and how sandboxes fit into a release process.
What is a sandbox in Salesforce?
A sandbox is a separate copy of your production org used to build and test changes safely. A sandbox is a separate environment created from your production org. You change things there first, test them, and only then deploy them to production. That keeps mistakes away from real customers and records, and gives testers and trainees a safe place to work. Salesforce's sandbox guide puts it simply: each sandbox inherits metadata from production, but only Partial Copy and Full Copy include data.
What are the Salesforce sandbox types?
There are four Salesforce sandbox types: Developer, Developer Pro, Partial Copy and Full. As of November 2026 they compare like this:
| Type | Copies | Data storage | File storage (sandbox guide) | Refresh interval | Best for |
|---|---|---|---|---|---|
| Developer | Metadata only | 200 MB | 5 MB | Once a day | Building and unit-testing one change |
| Developer Pro | Metadata only | 1 GB | 1 GB | Once a day | Larger builds and test data sets, integration work |
| Partial Copy | Metadata and a sample of data chosen by a sandbox template, up to 10,000 records per selected object | 5 GB | 5 GB | Every 5 days | Quality assurance and user acceptance testing |
| Full | Metadata and all production data | Same as production | Same as production | Every 29 days | Staging, performance tests, data migration rehearsals, training on real data |
Figures from Salesforce's sandbox guide; the 10,000-record figure is from Salesforce Help. File storage limits are listed differently on Salesforce's guide and its Help page on sandbox storage, so check your own org before you plan around them.
How many sandboxes do you get, and what do they cost?
Your edition decides which sandboxes are included; extra sandboxes are bought as add-ons. According to Salesforce Help's sandbox licences page, as of November 2026:
- Enterprise Edition includes 25 Developer sandboxes and one Partial Copy sandbox; a Full sandbox is not included.
- Developer Pro sandboxes can be bought for any edition.
- Partial Copy and Full sandboxes can be bought for Enterprise, Unlimited and Performance editions.
- Developer sandboxes are not sold on their own; they come bundled with add-on sandboxes of other types.
Salesforce doesn't publish one price list for sandboxes in its Help, so ask your account executive for add-on pricing, and check Setup, then Sandboxes for what your org already has. Our Salesforce edition comparison covers the editions themselves.
Which sandbox should you use?
Pick by how much data you need, how often you refresh and how complex the project is. Answer three questions, the same ones Salesforce's guide asks:
- How much data do you need to test with? None or a little you can create yourself: Developer or Developer Pro. A realistic sample: Partial Copy. Everything: Full.
- How often will you refresh it? Developer sandboxes can be refreshed daily; a Full sandbox only every 29 days, so it is a poor place for quick experiments.
- How complex is the project? A single admin change can go from a Developer sandbox straight to production. A multi-team programme usually needs a chain: Developer sandboxes for each builder, a Developer Pro or Partial Copy sandbox to integrate the work, and a Full sandbox for final testing.
A sandbox setup that works for most teams
Most teams do well with a four-stage chain: build, integrate, test and stage.
| Stage | Sandbox | Who uses it |
|---|---|---|
| Build | Developer, one per builder | Admins and developers |
| Integrate | Developer Pro | The delivery team, to combine and test changes together |
| Test | Partial Copy | Testers and business users |
| Stage | Full | Final checks with production data before release |
Smaller orgs can drop the integration step; larger ones add a training sandbox. Whatever the chain, move changes in one direction, from build to production, so environments don't drift apart. The Salesforce CLI and our DevOps guide cover how to move changes between them.
How to create and refresh a sandbox
You create and refresh sandboxes from Setup in production, under Sandboxes.
- In production, go to Setup → Sandboxes. The page shows how many sandboxes of each type your licences allow.
- Choose New Sandbox, name it, and pick the type.
- For a Partial Copy sandbox, choose a sandbox template: it decides which objects' data is copied.
- Wait for the copy to finish; a Full sandbox of a large org takes much longer than a Developer one.
- To refresh, use the Refresh action on the same page once the refresh interval has passed. Refreshing replaces everything in the sandbox, so deploy or export anything you want to keep first. Salesforce Help's refresh article covers the details.
How do you log in to a Salesforce sandbox?
Log in at test.salesforce.com with your production username plus a full stop and the sandbox name, for example user1@acme.com.uat, or use the sandbox's My Domain URL, which looks like MyDomainName--SandboxName.sandbox.my.salesforce.com. Salesforce Help's sandbox access article recommends the My Domain URL, and notes that after a create or refresh it can take 24 to 48 hours before test.salesforce.com works. Two inactivity rules matter, according to Help's login troubleshooting page: users who don't log in within 60 days of a create, refresh or clone are frozen, and a sandbox can expire after 180 days of inactivity.
A sandbox is different from a free Developer Edition org: a sandbox copies your company's org, while a Developer Edition is an empty org for learning.
Sandbox mistakes to avoid
The common mistakes are stale data, unprotected personal data, live integrations and building in shared sandboxes.
- Testing on stale data. A Full sandbox refreshed months ago no longer reflects production; schedule refreshes around releases.
- Forgetting real people's data. Partial Copy and Full sandboxes hold customer data, so restrict access and mask sensitive fields where your policies require it. Salesforce's sandbox guide points to Data Mask and Seed for realistic but non-sensitive test data.
- Live integrations in a sandbox. After a refresh, check endpoints and credentials so a sandbox doesn't email customers or post to real systems.
- Building directly in a shared test sandbox. Build in Developer sandboxes and deploy forward; otherwise nobody knows what changed.
- Skipping a rehearsal for data loads. Run large imports in a Partial Copy or Full sandbox first; see our Data Loader guide.
Getting help
A sandbox strategy is the backbone of a safe release process. Techila is a Salesforce Summit Partner; our managed services team runs environments and releases for Salesforce orgs, and our Workbench guide covers tools for moving data in and out of sandboxes. Talk to us about setting up a sandbox chain that fits your team.
Frequently asked questions
What is a sandbox in Salesforce?
A sandbox is a separate copy of your production org's configuration, and sometimes its data, where you can build, test and train without affecting live users or records. Changes are deployed to production once they have been tested.
What are the four types of Salesforce sandbox?
Developer and Developer Pro, which copy metadata only and differ in storage (200 MB and 1 GB of data); Partial Copy, which adds a sample of production data chosen by a template (5 GB of data); and Full, which copies all production data and has the same storage as production.
How often can you refresh a Salesforce sandbox?
Developer and Developer Pro sandboxes can be refreshed once a day, Partial Copy sandboxes every 5 days, and Full sandboxes every 29 days, according to Salesforce's sandbox guide.
Which sandbox should I use for user acceptance testing?
A Partial Copy sandbox when a representative sample of data is enough, and a Full sandbox when testing needs real data volumes, for example performance tests, data migrations or reports that depend on complete history.
How many sandboxes do I get?
It depends on your Salesforce edition and any extra sandbox licences you have bought. Check Setup, then Sandboxes, in your production org: it shows how many of each type you can create.