Sandbox
A Sandbox is a separate Salesforce environment that copies the metadata (and optionally the data) from a production org for development, testing, training, or staging purposes.
Definition
A Sandbox is a separate Salesforce environment that copies the metadata (and optionally the data) from a production org for development, testing, training, or staging purposes. Every nontrivial Salesforce project uses sandboxes: developers build in one, QA tests in another, training happens in a third, and a final staging sandbox mirrors production for pre-deployment validation. Sandboxes prevent the catastrophic mistakes that would otherwise happen if every change had to be made directly in production.
Salesforce offers four sandbox types, each tuned for a different stage of the development lifecycle. Developer sandboxes are smallest (200 MB data, refresh daily), best for individual feature work. Developer Pro sandboxes are larger (1 GB data, refresh daily), good for integration testing. Partial Copy sandboxes include a configurable subset of production data (5 GB), useful for UAT with realistic data. Full Copy sandboxes are a complete production replica including all data (matched storage), refresh every 29 days, and are the standard for staging environments. Each type has different storage allotments and refresh intervals that shape how teams use them.
How sandboxes structure the Salesforce development lifecycle
The four sandbox types and their trade-offs
Developer sandbox is the smallest (200 MB data, 200 MB file storage) and refreshes daily. Right for individual developer feature work. Developer Pro is larger (1 GB data, 1 GB file storage) with daily refresh, good for integration testing where multiple features merge. Partial Copy includes a configurable subset of production data (5 GB), refreshes every 5 days, and fits UAT with realistic data. Full Copy is a complete production replica including all data, refreshes every 29 days, and is the standard pre-production environment. Each org includes a baseline allotment; additional sandboxes cost extra.
Refresh cycles and the data freshness problem
Each sandbox type has a different refresh interval, which determines how often it can be reset to a fresh copy of production. Developer sandboxes refresh once per day. Partial Copy refreshes every 5 days. Full Copy refreshes every 29 days. The refresh interval matters because long-running sandboxes drift: data ages, schema can fall behind production hotfixes, and integration tests may pass against stale data. Mature teams schedule periodic refreshes to keep sandboxes useful, especially staging environments that should mirror production behavior closely.
Sandbox templates and selective data copy
Partial Copy and Full Copy sandboxes support sandbox templates: configurations that specify which objects to copy and what data filters apply. For example, copy only Accounts in California with their related Opportunities. Templates let teams build smaller, faster sandboxes that still contain the realistic data their use case needs. Without templates, a Partial Copy includes a sample of all data; with templates, it includes exactly what testing requires. Template design is a significant exercise on its own, especially for orgs with complex object relationships.
User and email handling on refresh
When a sandbox is refreshed, every user from production is copied with their settings, but the email addresses are scrambled (user@example.com.sandboxname) to prevent test emails from reaching production contacts. Passwords reset. Active users remain active; deactivated users remain deactivated. Permission sets, profiles, and role assignments come through. After refresh, the sandbox is fully usable but the running user usually needs to log in and reset their preferences. Email scrambling is a critical safety feature: without it, automated emails fired during testing would land in real customer inboxes.
The deployment and promotion pipeline
The standard Salesforce deployment pipeline promotes metadata changes from sandbox to sandbox toward production. Common patterns: Dev sandbox > Integration sandbox > UAT sandbox > Staging > Production, with appropriate sandbox types at each level. Change sets, metadata API, SFDX deployments, or third-party CI/CD tools (Copado, AutoRABIT, Gearset) move metadata between environments. Each promotion adds validation: tests pass, no governor limit regressions, no schema drift. The pipeline structure depends on team size and release cadence but the principle is consistent: never deploy directly to production.
Source of truth and the metadata drift problem
Sandboxes are not the source of truth; the version-controlled source code repository should be. Changes made directly in a sandbox without committing back to source control produce metadata drift: the sandbox accumulates work that lives nowhere else, vulnerable to refresh wiping it out. Mature teams enforce "no direct changes in sandbox; commit through source control" as the operational rule. This is also the foundation for proper code review, audit trails, and rollback capability that ad-hoc sandbox work cannot provide.
Common pitfalls and best practices
Pitfalls: refreshing a sandbox before saving the work in source control loses everything; using production email addresses for testing because email scrambling was disabled; assuming Full Copy sandbox is equivalent to production for performance testing (it shares hardware so concurrent users on production can impact sandbox performance); deploying to production from a sandbox that has not been refreshed in months and has drifted from production state. Best practices: refresh on a predictable schedule, version-control all metadata, validate deployments in a fresh sandbox before promoting to production, and document the sandbox hierarchy so new team members understand the pipeline.
How to create and use a Salesforce Sandbox
Creating a sandbox is mechanically simple: pick a type, name it, and submit the creation request. The harder work is designing the sandbox hierarchy, refresh schedule, and deployment pipeline that the sandbox fits into. Plan these before creating sandboxes ad-hoc, because the structure decisions persist across project lifecycles.
- Decide which sandbox type fits the use case
Developer for solo feature work. Developer Pro for integration testing. Partial Copy for UAT with realistic data. Full Copy for staging or pre-production validation. Pick based on what the sandbox will be used for, not on what fits the budget.
- Create the sandbox from production Setup
Production > Setup > Sandboxes > New Sandbox. Enter a name, description, and sandbox type. For Partial Copy or Full Copy, optionally select a sandbox template. Submit. Salesforce queues the creation; smaller sandboxes complete in minutes, full copies can take hours.
- Activate post-copy automation if needed
Specify an Apex class implementing SandboxPostCopy interface that runs after refresh. Common tasks: reset specific data values, anonymize PII, configure environment-specific settings. The script runs as the Automated User and has its own governor limits.
- Log in to the new sandbox
The sandbox login URL is yourdomain--sandboxname.sandbox.my.salesforce.com. Authenticate with your production username plus the sandbox suffix (.sandboxname). Reset the password if needed.
- Configure environment-specific settings
Update Named Credentials, External Data Sources, and any environment-specific configuration that should not be production. Switch debug mode on, configure test users, install development tools. This step is per-sandbox.
- Connect the sandbox to source control
Use SFDX to pull metadata to the local repo: sf project retrieve start. Push changes back when committing. The sandbox is a workspace, not the source of truth; source control is.
- Refresh on a predictable schedule
Plan when to refresh each sandbox: monthly for Full Copy staging, weekly for Partial Copy UAT, on-demand for Developer sandboxes after major production changes. Document the schedule so the team knows when work in a sandbox might be wiped.
- Deploy to production through the pipeline
Never deploy directly from a Developer sandbox to production. Promote through the chain: Dev > Integration > UAT > Staging > Production, with validation at each step. Use change sets, SFDX, or CI/CD tools for the actual deployments.
Developer, Developer Pro, Partial Copy, or Full Copy. Determines storage, refresh interval, and data inclusion.
Optional configuration for Partial Copy and Full Copy sandboxes specifying which objects and data filters apply.
Optional class implementing SandboxPostCopy interface that runs after each refresh for environment-specific setup.
- Refreshing a sandbox wipes everything not committed to source control. Save work to the version-controlled repo before refresh; the platform does not warn about lost changes.
- Email addresses are scrambled on refresh (user@example.com.sandboxname) to prevent test emails from hitting production contacts. Reset scrambling deliberately if testing requires real email delivery.
- Sandbox refresh intervals vary: Developer daily, Partial Copy every 5 days, Full Copy every 29 days. Plan refresh requests around the cooldown, especially for Full Copy where the wait is significant.
- Full Copy sandboxes share hardware with other tenants. Concurrent production load can impact sandbox performance. Do not use sandbox performance as a production performance benchmark.
- Sandbox templates require careful design. A template that misses a related object produces incomplete data in the sandbox, breaking tests that depend on the missing records.
Trust & references
Cross-checked against the following references.
- Sandbox OverviewSalesforce Help
- Sandbox TypesSalesforce Help
- Sandbox RefreshSalesforce Help
Straight from the source - Salesforce's reference material on Sandbox.
- Create a SandboxSalesforce Help
- Sandbox TemplatesSalesforce Help
- SandboxPostCopy InterfaceSalesforce Developer
Hands-on resources to go deeper on Sandbox.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is the primary benefit of Sandbox for Salesforce administrators?
Q2. Can a Salesforce admin configure Sandbox without writing code?
Q3. Why is understanding Sandbox important for Salesforce admins?
Discussion
Loading discussion…