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.