Salesforce has four sandbox types: Developer, Developer Pro, Partial Copy, and Full. Two questions decide which you need: do you need production data, and how much of it? Developer and Developer Pro copy metadata only. Partial Copy adds a sample of production data. Full copies all of it, for staging and load testing.
That's the short answer. The rest of this guide is about choosing well, because the four types differ on three things that shape your work: what data they copy, how much storage they hold, and how often you can refresh them. Get those straight and the choice mostly makes itself. The comparison table is right below, and there's a decision flow further down.
Salesforce sandbox types at a glance
Figures are from Salesforce's documentation on sandbox licenses and storage limits.
What is a Salesforce sandbox?
A sandbox is a copy of your production org in a separate environment. It's fully isolated, so anything you do in it (building a flow, breaking a validation rule, loading test records) has no effect on production. Every sandbox gets your production metadata. What else it gets depends on the type.
Teams use sandboxes for three reasons:
- Lower risk. Untested automation, misconfigured sharing rules, and broken integrations get caught before customers ever see them.
- A record of what changed. Building in a sandbox and promoting changes to production gives you a trail of what moved, when, and who approved it. Audit and compliance teams usually ask to see exactly that.
- Parallel work. Several developers or project teams can work at once without overwriting each other in production.
Here's what each type gives you.
What is a Developer sandbox for?
A Developer sandbox copies your production metadata (configuration, code, and customizations) and none of your records. It holds 200 MB of data, or 400 MB with a storage upgrade, and you can refresh it once a day.
It's the workhorse. One developer, one feature, no real data in the way. If the job is writing an Apex class, adjusting a flow, or checking that a change deploys cleanly, a Developer sandbox is usually enough. Salesforce also hands them out generously: Enterprise Edition includes 25, and Unlimited and Performance include 100. When you need to test the same change against realistic record volumes, move up a tier.
When does a Developer Pro sandbox make sense?
Developer Pro works like a Developer sandbox with more room. It still copies metadata only, but data storage rises to 1 GB (2 GB with an upgrade), and it refreshes on the same daily cycle.
The extra storage is the point. You can load larger data sets yourself, by hand or with a data-loading tool, which makes Developer Pro a good fit for integration testing, broader QA, and user training. You still don't get production data automatically. If your test depends on realistic data and you don't want to load it yourself, step up to Partial Copy.
What does a Partial Copy sandbox copy?
A Partial Copy sandbox copies all of your metadata plus a sample of production data. You define that sample with a sandbox template, which is required for this type. Salesforce's guidance puts the sample at up to 10,000 parent records with their related child records, within 5 GB of data storage. File storage matches your production org. You can refresh a Partial Copy every five days.
For many teams this is the sandbox they use most. You get real data to test against without the cost or the long refresh cycle of a Full sandbox, which makes it the usual home for QA, integration testing, UAT, and training. The catch is in the word "sample." Because it isn't the whole data set, it won't surface problems that only appear at full production volume. And the template decides exactly which records arrive. Build it carelessly and you'll test against the wrong data.
Read more: how Partial Copy sandboxes reduce risk and improve release quality.
What is a Full sandbox, and what's the catch?
A Full sandbox (often called a Full Copy sandbox) is a replica of production: all metadata and all data, including object records and attachments. Its storage matches your production org, and it has the longest refresh interval of the four at 29 days. Salesforce states that only Full sandboxes support performance testing, load testing, and staging.
Because it mirrors production, a Full sandbox is where you run the tests that have to be true to life: load and performance testing, staging a release, and final UAT. Two things catch teams out:
- The 29-day interval. You can't pull a fresh copy whenever you like. Salesforce itself notes the refresh interval makes Full sandboxes hard to use for development, so most teams treat them as stable staging environments and refresh them on purpose around release cycles.
- It holds real data. That includes anything sensitive. Masking or reducing that data after each refresh should be a standard step, not an optional one.
You can also apply a template to a Full sandbox to copy only the records you need, and choose whether to include field history and Chatter data. Leaving out data you don't need speeds up the copy.
Which Salesforce sandbox should you use?
Start from the job, not the tier. Ask what data the test needs and how close to production it has to be, then follow the flow.
Do you need a copy of production data?
- No, I need config and code in isolation.
- One person on a single change or small feature: Developer.
- Need more storage for larger data sets, integration testing, or training: Developer Pro.
- Yes, but a representative sample is enough.
- QA, integration testing, or UAT where a slice of real data does the job: Partial Copy. Plan your template carefully, because it decides what you're testing against.
- Yes, and it has to be the complete data set.
- Performance or load testing, staging, or final UAT against everything: Full. Plan around the 29-day refresh and mask sensitive data after each one.
In practice, mature teams run several types together. They build in Developer or Developer Pro, validate in Partial Copy, and stage the release in Full. Changes move up that chain one tier at a time and never skip straight to production.
How much do Salesforce sandboxes cost?
The number of sandboxes included with your org depends on your edition. Larger types are bought as add-ons.
You can buy extra Developer Pro sandboxes on any edition, and extra Partial Copy and Full sandboxes on Enterprise, Unlimited, and Performance. Developer sandboxes aren't sold on their own. They come bundled with the add-ons: 5 with each Developer Pro, 10 with each Partial Copy, and 15 with each Full. Salesforce doesn't publish list prices for sandbox add-ons, so ask your account executive for current pricing.
The practical point is simple. A Full sandbox is the most expensive way to test, because you're keeping a complete second copy of production. If a Partial Copy with the right template answers the question, it's cheaper to run and faster to refresh. Match the sandbox to the job and you won't pay for capacity you never use.
How do sandbox templates work?
Sandbox templates control which data is copied into a Partial Copy or Full sandbox. They're required for Partial Copy, optional for Full, and not available for Developer or Developer Pro.
When you build a template, you pick the standard and custom objects you want. The template editor reads your org's object relationships and adds any required related objects for you. For example, if Object A is the master of Object B and you select B, Salesforce adds A too. Three habits help:
- Copy only what the test needs. Smaller copies finish faster, and they keep unnecessary sensitive data out of lower environments.
- Keep relationships intact. A sample with orphaned child records will give you test results you can't trust.
- Review templates after schema changes. Salesforce can change a template automatically when required relationships change, so check that the objects you expect are still selected.
Can you clone a sandbox?
Yes. Instead of creating a sandbox from production, you can clone an existing sandbox. This is useful when one sandbox already holds a configuration or data set that another team needs. A cloned sandbox refreshes from its source sandbox rather than production, and it keeps the source's license type. If the source sandbox is deleted, the clone refreshes from production.
What happens when you refresh a sandbox?
A refresh updates the sandbox's metadata from its source org. If the sandbox uses a template or is a clone, its data is refreshed too. Three things are worth knowing before you press the button:
- The interval counts from your last request. Salesforce calculates the refresh interval from when you request the sandbox's creation or last refresh. That's 1 day for Developer and Developer Pro, 5 days for Partial Copy, and 29 days for Full.
- Anything built in the sandbox is replaced. Test data, in-progress configuration, and anything not yet deployed elsewhere will be overwritten. Back up or move it first.
- The org ID changes. Integrations and anything else that relies on the sandbox's org ID needs updating after each refresh.
Refreshing many sandboxes at once doesn't speed things up either. Salesforce processes copies one at a time, so a queue of refreshes takes longer than you'd expect.
Is a scratch org a sandbox?
No. A scratch org is a source-driven, disposable development environment you spin up from a definition file and discard, usually within days. It isn't one of the four sandbox types and it isn't a copy of your production org. If you see a guide claiming Salesforce has six sandbox types, it's probably counting scratch orgs (and sometimes a vendor's own product). There are four sandbox types. Scratch orgs are a separate tool for package-based development. For a side-by-side comparison, see scratch org vs. sandbox.
Sandbox best practices
Choosing a type takes a few minutes. Keeping your sandboxes useful is ongoing work. These practices prevent most of the common problems:
- Refresh on a schedule tied to releases. Refresh lower sandboxes after major production deployments so they don't drift from production.
- Promote changes upward only. Developer to Partial Copy to Full to production, and never sideways or backward.
- Mirror production security. Copy role hierarchies and permission sets, and rotate integration credentials between environments, so sandbox tests reflect real access.
- Mask sensitive data. Partial Copy and Full sandboxes carry real records. Mask or remove personal and regulated data after each refresh. See Salesforce data masking and how to prevent production data exposure in sandboxes.
- Watch storage. Salesforce doesn't email you when a sandbox hits its storage limit. You simply can't save new data. Check Storage Usage in Setup regularly.
- Keep a log. Record who refreshed what, when, and from which template, so problems can be traced.
Managing sandboxes at scale
Everything above is what Salesforce gives you out of the box. The friction starts when you run several sandboxes across several teams. Data has to be reseeded after every refresh, and sensitive records have to be masked every time. Developer sandboxes have no real data to test against, and a Full sandbox starts going stale the day after its 29-day refresh.
That ongoing work is what Flosum Sandbox Management handles, whichever sandbox types you use. New sandboxes are set up with production data seeded and sensitive fields masked, and they stay in sync with production between refreshes. A Developer sandbox becomes a realistic place to test, and you may need fewer Full sandbox licenses. For moving data between orgs more broadly, see Data Migrator.
Frequently Asked Questions
Book a meeting to see how Flosum keeps sandboxes seeded, masked, and in sync with production.
Thank you for subscribing
