Salesforce Sandbox Types: Developer, Pro, Partial, and Full
A complete guide to the four sandbox types — what they copy, how often they refresh, what they cost in licenses, and how to choose the right one for each project. Every detail verified against current Salesforce documentation.
What a sandbox actually is
A sandbox is a separate Salesforce org that mirrors your production org’s metadata — and, depending on type, some or all of its data. It runs on Salesforce infrastructure but is fully isolated: anything you do inside it has no effect on production. Sandboxes are how Salesforce customers develop, test, integrate, and train without breaking the live business.
Every sandbox has its own login URL (typically https://test.salesforce.com), its own Org ID, and its own users. Usernames carry the sandbox name as a suffix — so jane@example.com in production becomes jane@example.com.devbox in a sandbox named devbox. That suffix is one of the safety mechanisms Salesforce uses to prevent accidental cross-org logins.
What distinguishes the four sandbox types is a small but consequential set of attributes: storage limit, refresh interval, what gets copied (metadata only vs. metadata plus data), and license cost. Pick the wrong type and you either pay too much for a Full sandbox you don’t need, or run out of room in a Developer sandbox the day before a release.
All four sandbox types copy all of your production metadata — Apex classes, Lightning components, Flows, profiles, permission sets, page layouts, validation rules, custom objects, and so on. The differences are entirely about which records (if any) come along and how much room you have to work with.
The four types at a glance
Before diving into each type individually, this is the reference table — the one you should bookmark. Everything that follows expands on these specifications.
| Type | Storage (Data / Files) | What’s Copied | Refresh Interval | Templates |
|---|---|---|---|---|
| Developer | 200 MB / 200 MB | Metadata only | 1 day | No |
| Developer Pro | 1 GB / 1 GB | Metadata only | 1 day | No |
| Partial Copy | 5 GB / 5 GB | Metadata + sampled data (max 10,000 records per selected object) | 5 days | Required |
| Full | Same as production | Metadata + all data (and optionally Chatter, entity history, field history) | 29 days | Optional |
The four refresh intervals — 1 day, 1 day, 5 days, 29 days — and the four storage limits — 200 MB, 1 GB, 5 GB, production-equivalent — are the most frequently tested sandbox facts on the Admin, Platform Developer I, and Platform App Builder exams. Commit them to memory in that order.
Developer sandbox
The Developer sandbox is the smallest and most plentiful of the four. It includes a full copy of your production metadata but zero data — no Accounts, no Contacts, no records of any kind. Storage is capped at 200 MB for data and 200 MB for files, and the sandbox can be refreshed once per day.
Because Developer sandboxes are tiny and disposable, they are usually given to individual developers or admins for personal work: building a new Lightning component, scripting an Apex class, prototyping a Flow, or trying out a configuration change. The “no data” part is a feature, not a bug — there is nothing in the sandbox to break, and nothing sensitive to expose.
Individual dev work
- Coding Apex, LWC, Flows
- Quick prototyping
- Configuration trials
- Learning new features
Data-heavy work
- Integration testing
- Performance testing
- UAT with realistic volumes
- Training large user cohorts
To get data into a Developer sandbox, you load it yourself — using Data Loader, the Salesforce CLI’s data import commands, or an Apex class implementing the SandboxPostCopy interface (covered later). Because each refresh wipes the sandbox, automating that seeding is a habit worth forming early.
Developer Pro sandbox
The Developer Pro sandbox is a Developer sandbox with more headroom: 1 GB of data storage and 1 GB of file storage. It still copies only metadata, refreshes daily, and is intended for development and testing — but the extra capacity makes it suitable for team-shared development environments, integration smoke tests, and QA scenarios that need more than the trivial datasets a 200 MB Developer sandbox supports.
A Developer Pro sandbox is the right place to run developer-led QA. It can hold enough seeded data to exercise multi-step business processes without consuming a Partial Copy license. Reserve Partial Copy for tests that genuinely need a slice of production data, not test data that just happens to be larger.
Developer Pro sandboxes are particularly useful when multiple developers share a single environment for integration work — the kind of “team dev” sandbox that sits between individual Developer sandboxes and a more expensive Partial Copy or Full. They are not, however, intended to hold production data: there is no template mechanism, and there is no path for Salesforce to selectively copy records into them.
Partial Copy sandbox
The Partial Copy sandbox is the first type that copies actual production data. It includes all of your metadata plus a sampled subset of your production records — defined by a sandbox template — up to 5 GB of data, 5 GB of files, and a maximum of 10,000 records per selected object. It can be refreshed every five days.
The 10,000-record cap is per object, not per template, and Salesforce takes the first 10,000 records it encounters in object order. Related records on objects you didn’t select in the template are not pulled along automatically, which can create referential gaps — a Contact whose Account wasn’t included in the template, for instance, will not be copied. Sandbox templates are the lever for managing this; we cover them in the next section.
Partial Copy sandboxes are not a smaller Full. The sampling is shallow and rule-based — the first 10,000 records per selected object, with limited relationship awareness. If your test scenario depends on specific records or complete relationship graphs, either expand the template, load supplementary data after refresh, or use a Full sandbox.
Typical uses for Partial Copy include user acceptance testing, integration testing with realistic — but not exhaustive — data, training environments for small cohorts, and configuration testing against real records. Most enterprise Salesforce orgs maintain several Partial Copies in parallel for different project streams, since their 5-day refresh window lets a single team cycle through testing rapidly.
Full sandbox
The Full sandbox is a complete replica of production: all metadata, all data, all attachments, and — at your option during creation — Chatter feeds, entity history, and field history. Its storage limit matches your production org. It can be refreshed every 29 days, which makes it the slowest-cycling of the four types.
Full sandboxes are reserved for activities that genuinely need production-equivalent scale: performance testing, final regression before go-live, staging deployments, integration testing with high-volume data, and end-to-end UAT for major releases. They are also the only sandbox type appropriate for testing data migration scripts, since you need real distributions, real edge cases, and real volumes to know whether the migration will succeed in production.
Production-grade testing
- Pre-release regression
- Performance and load tests
- Data migration validation
- Staging deployments
- Final-stage end-to-end UAT
Daily development
- Individual dev work
- Quick prototyping
- Experimental config
- Anything you might want to throw away
Full sandboxes contain production data, including potentially sensitive PII, financial records, and protected health information. Treat them with the same security controls as production: restrict access, mask or anonymize sensitive fields after refresh, and never use a Full sandbox as a casual demo environment. Salesforce’s Data Mask add-on — now bundled with Salesforce Seeding and Salesforce Anonymize starting in Winter ’26 for Data Mask customers — automates much of that masking.
Sandbox templates: controlling what gets copied
A sandbox template is a saved selection of objects (and their related data) that defines what a Partial Copy or Full sandbox will pull from production on creation or refresh. Templates are required for Partial Copy and optional for Full. They do not apply to Developer or Developer Pro sandboxes, since those copy no data at all.
Templates are created in Setup under Sandboxes → Sandbox Templates. You pick the objects you want included; Salesforce handles the data copy at refresh time, subject to the storage cap and (for Partial Copy) the 10,000-records-per-object limit. The template can be edited between refreshes, so adjustments do not require a brand-new sandbox.
Why templates matter
Three reasons. First, storage control: a Partial Copy that tries to copy every object will overflow 5 GB on most production orgs. Second, focused testing: a UAT environment for the billing team probably doesn’t need every Marketing record. Third, compliance: excluding objects that hold sensitive data keeps that data out of lower environments entirely, which is cleaner than copying it in and then masking it.
If you maintain multiple Partial Copy sandboxes for different teams, build a template per team. A “Sales UAT” template might include Account, Contact, Opportunity, and Quote; a “Service UAT” template might include Account, Contact, Case, and Knowledge. Templates are reusable across sandbox refreshes, so the up-front investment pays off every cycle.
Licenses by edition
Sandboxes are consumed against license entitlements that come with your Salesforce edition. The exact entitlement varies by edition, and additional sandboxes can be purchased. The widely-published baselines are:
| Edition | Developer | Developer Pro | Partial Copy | Full |
|---|---|---|---|---|
| Professional | 10 | — | — | — |
| Enterprise | 25 | — | 1 | — |
| Performance | 100 | 5 | 1 | 1 |
| Unlimited | 100 | 5 | 1 | 1 |
Several rules of thumb apply across editions. Professional Edition does not include change sets — a meaningful limitation if you’re planning a declarative deployment workflow. A higher-tier sandbox license can be used to spin up a lower-tier sandbox (a Full license can create a Partial Copy or Developer), but not the reverse. Sandbox add-on packs are sold separately and stack on top of edition entitlements.
Verify your specific entitlements in your Salesforce contract and in the Setup → Sandboxes page, which shows current usage. License counts above are the widely-documented defaults; Salesforce reserves the right to update them.
The sandbox preview program
Three times a year — Winter, Spring, and Summer — Salesforce rolls out a major platform release. Roughly four to six weeks before each production release, sandboxes get the new release first. Your sandbox either gets the release early (on a preview instance) or stays on the current release until production catches up (on a non-preview instance).
You don’t choose preview vs. non-preview by clicking a button. You choose by when you refresh. Refresh before the cutoff date Salesforce publishes for that release, and your sandbox lands on a preview instance. Refresh after the cutoff, and it lands on a non-preview instance. The cutoff and instance assignments are published in the Salesforce Sandbox Preview Guide for each release.
Why preview matters
Sandbox preview is how customers test their customizations against the new release before it hits production. Critical regression testing, deprecated API checks, third-party AppExchange app compatibility, and any configuration that touches changed-behavior areas should happen on a preview sandbox. Salesforce’s recommendation — and the practical baseline — is to maintain at least one preview sandbox for each release cycle.
Sandbox preview behavior is tested on multiple admin and developer exams. Two facts to lock in: (1) the preview instance assignment is determined by refresh timing, not a setting; and (2) deploying between a preview sandbox (newer API version) and a non-preview sandbox (older API version) can fail due to metadata version mismatches.
Creating, cloning, and refreshing sandboxes
Sandbox creation, cloning, and refresh all happen in Setup → Sandboxes in your production org, or programmatically via the Salesforce CLI and Tooling API. The user performing the action needs the Manage Sandboxes system permission, which is included in the System Administrator profile by default.
Creation flow
- From Setup, search for Sandboxes and click New Sandbox.
- Enter a sandbox name (kept short — it becomes a username suffix) and description.
- Select the sandbox type. Only types you have available licenses for will be enabled.
- For Partial Copy or Full, optionally select a sandbox template to control which objects are copied.
- Optionally specify an Apex class that implements
SandboxPostCopyto run after creation. - Click Create. Salesforce emails the requester when the sandbox is ready (typically minutes to hours for Developer, hours to days for Full depending on data volume).
Cloning
Sandbox cloning creates a new sandbox from an existing one rather than from production. It copies the source sandbox’s data and metadata, including (for Full sandbox clones) entity history and Chatter data if those were in the source. The cloned sandbox uses the same license type as the source, and access is granted to all active users of the source — you cannot restrict the user set during cloning. Cloning is useful when you want a stable starting point for parallel work streams without consuming additional production refresh cycles.
Refresh
Refreshing a sandbox replaces its contents with a fresh copy from the source org. For a sandbox originally created from production, that source is production; for a cloned sandbox, the source is the sandbox it was cloned from. Refresh creates a brand-new org behind the scenes — a new Org ID, new user records, new OAuth tokens — and deletes the previous one once activation completes.
A refresh cannot be undone. Once you activate the refreshed sandbox, everything in the previous version is gone — code that hadn’t been committed, ad-hoc data you’d loaded, configuration changes that hadn’t been deployed back. The only safe recovery is to have deployed those changes out (to version control or another org) before refreshing.
What happens after a refresh
A refresh isn’t just a data copy — Salesforce makes several safety-oriented changes to the sandbox to prevent it from interfering with production or external systems. These changes are why every team needs a post-refresh checklist.
.invalidjane@example.com becomes jane@example.com.invalid — preventing accidental outbound mail to real users.SandboxPostCopy: automating the cleanup
Salesforce provides the SandboxPostCopy Apex interface (in the System namespace) for running code automatically when a sandbox finishes creation or refresh. You specify the class during sandbox creation or in the sandbox definition file. A typical implementation will reset Named Credentials, repopulate Custom Settings or Custom Metadata Type records, load seed data, mask sensitive fields, deactivate test users, or activate the integrations that should run in the sandbox.
global class PrepareSandbox implements SandboxPostCopy {
global void runApexClass(SandboxContext context) {
System.debug('Org ID: ' + context.organizationId());
System.debug('Sandbox: ' + context.sandboxName());
// Reset integrations, load seed data, mask PII, etc.
}
}
Build your SandboxPostCopy class once and reuse it across every sandbox refresh. Drive its behavior from a Custom Metadata Type — sandbox-specific endpoint URLs, integration usernames, seed data flags — so the same class behaves correctly in every environment. This eliminates the most error-prone manual step in the refresh process.
Choosing the right type for the job
The defensible rule of thumb: use the smallest sandbox that meets your needs. Smaller sandboxes refresh faster, cost less in license consumption, and are easier to keep clean. Reach for larger types only when the use case genuinely requires the data or volume they provide.
| If you need to… | Reach for… |
|---|---|
| Build a new Apex class, Flow, or LWC for personal work | Developer |
| Set up a team-shared dev environment with seeded test data | Developer Pro |
| Run UAT or integration tests against realistic — but not exhaustive — production data | Partial Copy |
| Train a focused user cohort on real-looking data | Partial Copy |
| Run final regression before a major release | Full |
| Test a data migration script with real distributions and volumes | Full |
| Performance-test against production-equivalent data | Full |
| Stage a deployment that will go to production next week | Full |
Most mature Salesforce DevOps pipelines use all four types in combination: many Developer sandboxes for individual builds, one or two Developer Pro sandboxes for team dev, two to four Partial Copy sandboxes for UAT and integration, and one Full sandbox for staging and final regression. Changes flow upstream through the chain, with each tier validating different aspects of the work.
10 Key Exam Tips on Sandboxes
- Storage limits — Developer 200 MB, Developer Pro 1 GB, Partial Copy 5 GB, Full = production. Files and data share the same limits per type for Developer, Developer Pro, and Partial Copy.
- Refresh intervals — Developer and Developer Pro every 1 day, Partial Copy every 5 days, Full every 29 days. These are minimum waits from last refresh or creation.
- Data copy behavior — Developer and Developer Pro copy no records. Partial Copy and Full copy data; only Partial Copy and Full support templates.
- Partial Copy cap — 5 GB total and 10,000 records per selected object. Related records on unselected objects do not tag along automatically.
- Sandbox templates — Required for Partial Copy, optional for Full, unavailable for Developer and Developer Pro.
- Sandbox preview — Determined by when you refresh, not by a toggle. Refresh before cutoff = preview; after cutoff = non-preview.
- After a refresh — New Org ID, user emails appended with
.invalid, Email Deliverability set to System email only, scheduled jobs deactivated, OAuth tokens invalidated. SandboxPostCopy— Apex interface for automating post-refresh setup. Class must exist in the source org and be specified at sandbox creation or in the definition file.- Cloning — Creates a new sandbox from an existing sandbox, not from production. Cloned sandboxes use the source sandbox’s license type and cannot be restored if deleted.
- License hierarchy — A higher-tier sandbox license can create a lower-tier sandbox (Full license can create a Partial Copy or Developer), but not the reverse.
Frequently asked questions
Salesforce offers four sandbox types: Developer (200 MB, metadata only, refresh daily), Developer Pro (1 GB, metadata only, refresh daily), Partial Copy (5 GB, metadata plus sampled data via a template, refresh every 5 days), and Full (same storage as production, metadata plus all data, refresh every 29 days).
A Partial Copy sandbox has a 5 GB data storage limit and a 5 GB file storage limit. It can include a maximum of 10,000 records per selected object, defined by the sandbox template.
Developer and Developer Pro sandboxes can be refreshed once per day. Partial Copy sandboxes can be refreshed every 5 days. Full sandboxes can be refreshed every 29 days. These intervals run from the date of last creation or refresh, and they apply even if you delete the sandbox in between.
No. Developer and Developer Pro sandboxes copy your production org’s metadata — objects, fields, Apex, Flows, profiles, layouts, and so on — but no records. To get records into these environments, load sample data manually, via the Salesforce CLI, or by using a SandboxPostCopy Apex class.
A sandbox template lets you choose which objects and related data are copied to a sandbox during creation or refresh. Templates are required for Partial Copy sandboxes and optional for Full sandboxes. They help control sandbox size, focus testing on relevant data, and limit exposure of sensitive records.
Sandbox preview is the window — typically six weeks before each Salesforce production release — during which sandboxes on a preview instance receive the new release early. Refreshing or creating a sandbox before the cutoff date places it on a preview instance; refreshing after the cutoff places it on a non-preview instance, which keeps the current release until production upgrade.
A refresh creates a new org with a new Org ID, replacing the previous sandbox content. Email Deliverability defaults to System email only, user email addresses are appended with .invalid to prevent accidental outbound mail, scheduled jobs are deactivated, and OAuth tokens tied to the old Org ID stop working. Plan to reauthenticate integrations and re-enable schedules after every refresh.