Salesforce Sandbox: Complete Guide
Quick Summary:
A sandbox is an isolated copy of your Salesforce org for building and testing changes safely, without affecting production. Four types exist, each with different data inclusion, storage, and refresh limits.
What Is a Salesforce Sandbox?
A sandbox is a separate, isolated environment that copies your production org's metadata (configuration, code, and optionally data) so you can build, test, and validate changes without any risk to live business operations. Every serious Salesforce implementation uses sandboxes as a standard part of the development and deployment process.
⚠️ Before You Start
Refreshing a sandbox completely wipes existing configuration and data in that sandbox, replacing it with a fresh copy. Never do significant work in a sandbox scheduled for refresh without a plan to redeploy or back up that work first.
The Four Sandbox Types
| Sandbox Type | Includes Data | Storage | Min Refresh Interval |
|---|---|---|---|
| Developer | No (metadata only) | 200 MB | 1 day |
| Developer Pro | No (metadata only) | 1 GB | 1 day |
| Partial Copy | Sample data (via template) | 5 GB | 5 days |
| Full | Complete production copy | Same as production | 29 days |
How to Create One
Go to Setup → Sandboxes and click New Sandbox.
Choose the sandbox type based on your needs (Developer for quick config work, Full for realistic data-volume testing).
Name it clearly (e.g. "UAT" or "DevQ1") — this name becomes part of every user's sandbox login.
For Partial Copy, select or build a sandbox template defining which data to include.
Submit and wait for the creation process to complete (timing varies significantly by type and org size).
A Real-World Example
A team is building a significant Flow automation change that touches Opportunity and Case records. Rather than building and testing directly in production — where a mistake could genuinely disrupt live sales or support operations — the team builds and thoroughly tests in a Developer sandbox first, then validates with realistic data volume in a Partial Copy sandbox before finally deploying to production via change set.
🚫 Common Mistake
Building complex configuration directly in production because setting up a sandbox feels like an extra step. Every mistake made directly in production is immediately live — the small time investment in sandbox testing is consistently cheaper than the cost of an untested change breaking something real users depend on.
💡 Pro Tip
Keep a dedicated, rarely-refreshed sandbox for ongoing development work, separate from a UAT sandbox that gets refreshed more frequently to stay aligned with current production data — using one sandbox for both purposes tends to create conflicts.
Frequently Asked Questions
How do I log into a sandbox?
Sandbox URLs follow the pattern [yourdomain]--[sandboxname].sandbox.my.salesforce.com, or you can navigate via Setup → Sandboxes and click the sandbox name from your production org.
Why is my username different in the sandbox?
Salesforce automatically appends the sandbox name to your username (e.g. user@company.com.devsandbox) to keep it globally unique across environments — this is expected, not an error.
How long does a sandbox refresh take?
Depends on type and org size: Developer sandboxes typically refresh in minutes to an hour; Full sandboxes with large data volumes can take considerably longer, sometimes 24+ hours.
Can I refresh a sandbox at any time?
No — each sandbox type has a minimum refresh interval (1 day for Developer/Developer Pro, 5 days for Partial Copy, 29 days for Full) that must pass before another refresh is allowed.
Does refreshing a sandbox delete my changes?
Yes — a refresh completely overwrites the sandbox with a fresh copy from production (or the template, for partial copy), discarding any configuration or data changes made since the last refresh.
Can I choose which data comes into a sandbox?
For Partial Copy sandboxes, yes, via a sandbox template that defines which objects and how many records to include. Full sandboxes copy everything; Developer sandboxes include no data by default.
How many sandboxes can my org have?
Limits depend on your Salesforce edition and license — Enterprise Edition typically includes a set number of each sandbox type, with additional sandboxes available for purchase.
Are sandbox emails sent to real customers?
By default, sandboxes have email deliverability restricted to prevent accidentally emailing real customers during testing — this can be adjusted but should be treated carefully.
Can I deploy changes from a sandbox to production?
Yes, via change sets, a metadata deployment tool, or CI/CD pipelines connected to version control — sandboxes are specifically designed as a safe staging area before production deployment.
What\'s the difference between a sandbox and a scratch org?
A sandbox is a copy of your existing production org's metadata (and optionally data); a scratch org is a temporary, disposable environment built from source-controlled metadata, more common in modern DevOps workflows.