Salesforce Sandbox Types: Which One Should You Use?

Salesforce sandboxes are isolated copies of your production org where you can build, test and train without touching live data or users. There are four types: Developer and Developer Pro copy metadata only and refresh daily, Partial Copy adds a sample of data and refreshes every 5 days, and Full copies all data and refreshes every 29 days.

Key takeaways

• A Salesforce sandbox is a copy of your production org. The type you pick decides how much data it holds, how often you can refresh it and what it costs.
• Developer and Developer Pro sandboxes copy metadata only and refresh daily. Partial Copy adds a sample of data and refreshes every 5 days. Full Copy refreshes every 29 days.
• Give every builder a Developer sandbox, use Partial Copy for user acceptance testing, and keep Full Copy for release rehearsal and load testing.
• Whatever the type, the refresh is the dangerous moment. Deploy your work out before you press the button.

Most Salesforce teams don't have a sandbox problem. They have a sandbox job description problem.

Someone buys a Full sandbox, uses it for everything, refreshes it twice a year and wonders why testing feels unreliable. If you're an admin, choosing the right salesforce sandbox for each job is one of the cheapest ways to stop breaking production.

My argument is simple: pick the sandbox by the data your test needs, not by how important the change feels. The refresh limit then sets your rhythm, and the price tells you how few Full sandboxes you should be using.

What is a Salesforce sandbox?

A Salesforce sandbox is an isolated copy of your production org where you can build, test and train without touching live data or users.

Salesforce describes it as a safe space for development, testing and training. Operations you perform in a sandbox don't affect your production org.

Two things trip people up early. A sandbox is not a backup of production. And it is not a scratch org; Salesforce's developer blog on choosing the right org explains the differences between a sandbox, a scratch org and a Developer Edition org.

Salesforce sandbox types compared: Developer, Developer Pro, Partial Copy and Full

The four types differ on three things: how much data they carry, how often you can refresh, and what you pay.

	Developer	Developer Pro	Partial Copy	Full
Copies	Metadata only	Metadata only	Metadata plus a sample of data chosen by a sandbox template	Metadata plus all data
Data storage	200 MB	1 GB	5 GB	Same as production
File storage	200 MB	1 GB	5 GB	Same as production
Refresh interval	1 day	1 day	5 days	29 days

Storage and refresh figures come from Salesforce Help: Sandbox Types and Templates. For Partial and Full, confirm your exact rate on that page and in your order form, because it depends on your contract.

Two limits matter more than they look. A Partial Copy template defines a sample of your production data, so you're testing against a slice of reality. And how many of each type you get depends on your edition. Open Setup, search for Sandboxes, and the counts are at the top of the page.

Which Salesforce sandbox should I use? A decision table by use case

Match the job to the cheapest sandbox that holds the data that job needs.

Use case	Best type	Why
One admin building a Flow, page layout or validation rule	Developer	Metadata is enough; daily refresh keeps it close to production
Several admins or developers working in one environment, or a larger metadata footprint	Developer Pro	The same metadata-only copy, with 1 GB of storage for seeded test data
Testing an AppExchange package before production	Developer or Developer Pro	Install and break things freely; see my AppExchange evaluation guide
User acceptance testing with realistic records	Partial Copy	A template-selected sample gives testers real-looking accounts and cases
End-user training	Partial Copy (or Developer Pro with seeded data)	Trainers need data that looks like the job
Integration testing against a staging system	Partial Copy or Full	Depends on how much data the integration needs to see
Performance, load and data-volume testing	Full	Only Full carries production-scale data
Rehearsing a big release or data migration	Full	You get a realistic dry run, including timing
Testing an Agentforce agent against realistic cases	Partial Copy or Full	Judgement: agents behave differently with thin data; Salesforce also covers environment choices for agent development

My take: Don't use your Full sandbox for day-to-day UAT. With a 29-day refresh limit, a Full sandbox is a release-rehearsal environment, and the teams that treat it as the default test org end up with stale data and a queue of people waiting for it. This is my judgement, not a Salesforce rule, but I'd defend it in any review meeting.

How to create a Salesforce sandbox, step by step

You can create a sandbox in a few clicks, but the choices you make on the form decide how useful it is.

1. In Setup, enter Sandboxes in Quick Find and select Sandboxes.
2. Click New Sandbox.
3. Enter a name (keep it short; it becomes part of every username) and a description.
4. Choose the type. For Partial Copy or Full, choose a sandbox template to decide which objects and data come across.
5. Optionally, choose an Apex class to run after the copy completes (see below).
6. Click Create, then wait for the email that says it's ready.

Salesforce's Trailhead unit on setting up a sandbox walks through the same flow in a practice org.

What is a Salesforce sandbox post-copy script, and why use one?

A sandbox is a copy of production, so it can still point at production's integrations unless you tell it otherwise.

A post-copy script is an Apex class that implements the SandboxPostCopy interface; you pick it when you create or refresh the sandbox, and it runs after the copy completes. Here's a minimal example, using a hypothetical custom setting:

global class PrepSandbox implements SandboxPostCopy {
    global void runApexClass(SandboxContext context) {
        // Point integrations at test endpoints, not production
        Integration_Settings__c s = Integration_Settings__c.getOrgDefaults();
        s.Endpoint__c = 'https://test.example.com/api';
        upsert s;
        System.debug('Prepared sandbox: ' + context.sandboxName());
    }
}

Use it to reset endpoints, switch off outbound integrations, and seed test users. If you write triggers in a sandbox, test them with more than one record; my guide to a bulk-safe Apex trigger shows why.

How Salesforce sandbox refresh works, and what it wipes

A refresh replaces your sandbox with a fresh copy of production, so anything not deployed out is gone.

The interval in the table is the minimum wait between refreshes. For a Full sandbox, that's 29 days, so a mistimed refresh costs you a month. After a refresh, expect these changes:

• Your sandbox metadata matches production again. Unsaved or undeployed work disappears.
• Email deliverability on a new sandbox defaults to system email only. Check it before you test notifications.
• Large Partial or Full copies can take a long time to finish, so schedule them away from test windows.

My take: Put refresh dates in the team calendar and make "deployed or exported?" a formal question the day before. The most expensive sandbox mistake I see in admin teams isn't a bad configuration. It's a refresh that erased two weeks of someone's unreleased work.

Common Salesforce sandbox mistakes

Almost every sandbox failure is a process failure, not a product failure.

• Treating the sandbox as a backup. It isn't one, and it can't restore production data.
• Testing a Flow with no realistic data. A Developer sandbox has no records, so a record-triggered Flow can look fine and fail on first contact with real data, and it helps to know where it sits in the order of execution in Salesforce next to your Apex triggers. Use my guide on how to debug a Salesforce Flow when it does.
• Leaving real customer data unprotected. Partial and Full sandboxes carry production records. Mask sensitive fields, limit who can log in, and check your obligations, such as India's DPDP Act or GDPR.
• Forgetting integrations. Named credentials and endpoints can still reach production systems after a copy.
• Buying a Full sandbox "just in case". If your testing never needs production-scale data, a Partial Copy and a good template may do.

Admin interviewers love these scenarios, by the way. If you're preparing, my Salesforce admin interview questions cover several.

What to do this week with your Salesforce sandboxes

• Open Setup > Sandboxes and write down which types and how many you have, and when each was last refreshed.
• Map each sandbox to one job in a single line ("UAT", "release rehearsal", "Rahul's Flow build") and retire any with no owner.
• Write a post-copy Apex class that resets integration endpoints, and attach it to your next refresh.
• Check your sandbox rate on the pricing page against your order form, then ask whether a Full sandbox is earning its cost.

If you want help designing an environment strategy for your org, get in touch.

More guides like this are on the Salesforce AI hub.

Frequently asked questions

What are the different Salesforce sandbox types?

There are four: Developer, Developer Pro, Partial Copy and Full. Developer and Developer Pro copy metadata only, Partial Copy adds a template-defined sample of data, and Full copies everything. See Salesforce Help for the official definitions.

How often can I refresh a Salesforce sandbox?

Developer and Developer Pro can be refreshed once a day, Partial Copy every 5 days and Full every 29 days. The interval is the minimum wait between refreshes.

Does a Salesforce sandbox cost extra?

Check the sandbox pricing page and your contract for sandbox costs. Other types are priced as a share of your spend, so check the sandbox pricing page and your contract.

What is the difference between a sandbox and a scratch org?

A sandbox is a copy of your production org, while a scratch org is a different org type used for source-driven development. Scratch orgs suit source-driven teams; sandboxes suit testing against your real configuration.

Which sandbox is best for UAT?

Partial Copy is usually the best fit, because it gives testers realistic data at a lower cost and with a shorter refresh interval than Full. Use Full when UAT needs production-scale volumes.