Salesforce Sandbox: What It Is and How to Use It
A sandbox is a copy of your production Salesforce org used for testing changes before they go live. If you're making any change to a real Salesforce org without a sandbox, you're betting your company on getting it right the first time. That bet doesn't pay.
This guide covers the four sandbox types, when to use each, the refresh and deployment workflow, and the safety rules that prevent disasters.
Estimated read time: 8 minutes
The four sandbox types
| Type | Includes | Refresh | Storage |
|---|---|---|---|
| Developer | Metadata only, no data | Daily | 200 MB |
| Developer Pro | Metadata only, no data | Daily | 1 GB |
| Partial Copy | Metadata + sample data | Every 5 days | 5 GB |
| Full | Metadata + all data | Every 29 days | Same as production |
Pick based on what you're doing:
- Building/testing config or code in isolation: Developer
- Larger code projects, multiple devs: Developer Pro
- Testing with realistic data subsets: Partial Copy
- Performance testing, training, UAT with full data: Full
Most orgs run a Full sandbox for UAT, plus 2-3 Developer sandboxes for individual contributors.
Creating a sandbox
Setup → search Sandboxes → New Sandbox:
- Name (max 10 chars, alphanumeric)
- Description
- Type
- Source Org (production by default; for some types you can clone from another sandbox)
- Create
Sandboxes take 30 minutes to several hours to provision depending on type.
Refresh strategy
Refreshing a sandbox replaces it with a fresh copy from production. All custom data and config in the sandbox is wiped.
Best practices:
- Developer sandboxes: refresh weekly or per-project
- Partial Copy: refresh before each major UAT cycle
- Full sandbox: refresh quarterly, or after major data changes in production
Schedule refreshes around release cycles. Don't refresh mid-sprint or you'll lose work.
What gets copied vs not
Copied to all sandbox types:
- All metadata: objects, fields, page layouts, validation rules, flows, Apex
- Profiles, permission sets, roles
- Email templates, reports, dashboards
Copied only to Full and Partial:
- Records (Full = everything; Partial = sampled data per template)
Never copied:
- Marketing Cloud connections (need re-authentication)
- Some integration credentials (need re-entry)
The deployment workflow
The standard flow for any production change:
- Make the change in a sandbox (Developer or Developer Pro)
- Test it with realistic scenarios
- Get review from a peer admin or developer
- Deploy to a UAT sandbox (Full or Partial Copy) for stakeholder testing
- Stakeholder sign-off
- Deploy to production during a low-traffic window
Skip steps and you'll regret it.
Deployment tools
Choose based on team size and complexity:
- Change Sets — Salesforce-native, click-based. Fine for small teams, simple changes.
- Salesforce DevOps Center — modern Salesforce tool, free
- Gearset / Copado / AutoRABIT — third-party DevOps platforms, paid, much more powerful
- SFDX + Git — for development-heavy teams, full version control
For most orgs we work with: DevOps Center is the right starting point. Move to Gearset or Copado when you have 3+ developers.
The 6 safety rules that prevent prod-breaking accidents
- Never edit production directly for non-trivial changes. Even "small" changes break things.
- Test deployments in a sandbox before deploying to production. Deploy to a sandbox first → run validation → deploy to production.
- Use validation-only deployments as a dry run.
- Schedule production deployments during low-traffic windows. Friday afternoons are bad. Sunday mornings are good.
- Have a rollback plan. Document what to do if the deployment fails midway.
- Notify users before/after. Even if nothing breaks, surprises erode trust.
Want sandbox + deployment hygiene set up for you?
Most Salesforce orgs we audit have either no sandbox strategy or one nobody follows. Setting up a working sandbox structure, deployment process, and team norms is a 1-2 week project.
RevKit's DevOps Setup delivers it in 48 hours for $1,499:
- Sandbox structure design (Dev / UAT / Prod flow)
- DevOps Center configuration with team workflows
- Change set vs DevOps Center decision per use case
- Documentation and runbooks
- Team training session