Four Types, Different Purposes
Salesforce offers four sandbox types, each with different data, storage, and refresh characteristics. Using the wrong type wastes resources; using the right type saves time and money.
- Developer Sandbox
- Developer Pro Sandbox
- Partial Copy Sandbox
- Full Sandbox
Developer Sandbox
What it is: a copy of your production org’s metadata — no data.
Storage: 200 MB data + 200 MB files.
Refresh: once per day.
Cost: typically included (varies by edition).
Use for: individual developer work, quick feature exploration, unit test development, short-lived experiments.
Don’t use for: integration testing that needs realistic data, UAT, performance testing.
This is the default sandbox for routine development. Most developers have one each.
Developer Pro Sandbox
What it is: a copy of your production org’s metadata — no data — with more storage than a regular Developer Sandbox.
Storage: 1 GB data + 1 GB files.
Refresh: once per day.
Cost: extra-cost SKU; available in specific editions.
Use for: development requiring more sample data, larger test datasets, longer-lived developer environments.
Don’t use for: anything you’d use Developer Sandbox for (overpayment) or anything you’d use Partial Copy for (insufficient data realism).
Partial Copy Sandbox
What it is: metadata + a sample of production data as defined by a Sandbox Template.
Storage: 5 GB data + 5 GB files.
Refresh: every 5 days.
Cost: extra-cost; some editions include one.
Use for: UAT with representative data, integration testing against production-like records, QA environments that need real data shapes.
Don’t use for: training (data is shared across users), production-scale performance testing (too small).
Sandbox Templates are critical here. A template specifies which objects and how many records to copy. A bad template leaves out key records; a template without filters might copy the wrong segments.
Full Sandbox
What it is: a complete copy of production — metadata and all data.
Storage: matches production.
Refresh: every 29 days.
Cost: extra-cost; usually one included in higher editions.
Use for: full-scale UAT, performance testing, data migration rehearsals, final pre-release verification.
Don’t use for: routine development (too big and slow), training environments (too expensive).
Refresh cadence is the gotcha — once every 29 days. If production data is moving fast, your Full sandbox is stale within days of refresh.
Comparison at a Glance
| Feature | Developer | Developer Pro | Partial Copy | Full |
|---|---|---|---|---|
| Data | None | None | Sample | Complete |
| Storage | 200 MB | 1 GB | 5 GB | = Prod |
| Refresh frequency | Daily | Daily | 5 days | 29 days |
| Cost | Included | Extra | Extra | Extra |
| Typical use | Dev | Dev with data | UAT | Pre-prod |
Sandbox Templates
A template defines which objects and how many records to include in a Partial Copy or Full Sandbox refresh.
Template design:
- Include all metadata dependencies. If your custom object references another, include both.
- Limit sensitive data. Exclude or mask PII fields.
- Sample selectively. 10,000 records per object is usually enough for functional testing; more for performance testing.
Templates are reusable and deployable metadata. Maintain them alongside your configuration.
Data Masking
Partial and Full Sandboxes contain production data. If that data is regulated (PII, PCI, PHI), refreshing to a sandbox without masking creates a compliance risk.
Options:
- Data Mask (paid Salesforce feature) — automates masking post-refresh.
- Custom mask scripts — Apex jobs that run post-refresh to anonymize.
- AppExchange packages — third-party tools with domain-specific masking.
Never give testers access to production-sensitive data in a sandbox. Masking is not optional in regulated environments.
Sandbox Strategy for a Healthy Org
A typical production-quality environment has:
- Several Developer Sandboxes — one per developer or feature team.
- One or two Developer Pro Sandboxes — for work needing more data or longer life.
- A Partial Copy Sandbox — QA environment, refreshed every 5 days, used for release UAT.
- A Full Sandbox — pre-production, refreshed before major release deployments.
This is a baseline. Teams with heavy Salesforce investments often add:
- Training sandboxes.
- Integration test sandboxes with specific data loads.
- Red-team / security-review sandboxes.
Migration Pattern
New code flows:
- Developer builds in their Developer Sandbox.
- Merges to a shared Dev branch; CI deploys to a shared sandbox.
- Deploys to Partial Copy for QA.
- Deploys to Full for UAT with realistic data.
- Deploys to production.
Five stages is heavy; not every org needs all five. Small teams may collapse to three (Dev → UAT Partial Copy → Prod). The right number depends on risk tolerance and release cadence.
Common Mistakes
Skipping Full Sandbox before major releases. Bugs that only appear at scale get caught in production otherwise.
Not refreshing Full Sandbox before use. Data drift — production moved on, sandbox didn’t — produces misleading UAT.
Giving too many users access to Full Sandbox. It’s expensive and shared; limit to people who need realistic data.
Forgetting sandbox templates. Partial Copy without a template copies a default set; may miss important custom objects.
Using Production for testing. Because sandboxes are “too slow” or “out of date.” This is how incidents happen.
Sandbox Refresh Process
To refresh:
- Setup → Sandboxes → Refresh.
- Pick the type.
- Select a template (for Partial Copy or Full).
- Name the sandbox.
- Wait — refreshes can take hours to days for large Full sandboxes.
Post-refresh, re-apply any sandbox-only configuration that you don’t want overwritten (test users, integration endpoints pointing to test external systems).
Frequently Asked Questions
Can I move data between sandboxes?
Yes — via Data Loader or third-party tools. You can also promote data from a Developer Sandbox to Partial Copy as needed.
How do I know when a sandbox was last refreshed?
Setup → Sandboxes shows the last refresh date. Automate reminders for periodic refreshes.
Are sandbox IDs different from production?
Yes — record IDs differ between orgs. Integrations configured for production need to be re-pointed for sandbox testing.
Can I have sandboxes in different Salesforce editions?
Sandboxes inherit from production’s edition. You can’t mix edition types.