What You'll Learn
The four sandbox types and their data limits, the right sandbox for each stage of the SDLC, refresh cycle planning, sandbox data masking for compliance, and how scratch orgs fit into a modern CI/CD pipeline alongside traditional sandboxes.
The Four Sandbox Types
Developer Sandbox contains all metadata from production but no data records. Storage is 200 MB of data and 200 MB of files. Included in all editions; orgs have as many as they purchase. Refreshes in minutes. Ideal for individual developer feature work and code experimentation.
Developer Pro Sandbox is identical to Developer but with 1 GB of data and 1 GB of files. Useful when developers need some data volume to test governor limit behaviour but a Full sandbox is not available.
Partial Copy Sandbox copies all metadata plus a sample of data based on a Sandbox Template you define. Storage is 5 GB. Refresh cycle is 5 days minimum. Ideal for integration testing with realistic (but not full-volume) data.
Full Sandbox copies all metadata and all data — a complete replica of production. Storage mirrors production. Refresh cycle is 29 days minimum. Very expensive (costs roughly 10-15% of the production licence cost annually). Ideal for performance testing, UAT, and staging.
Sandbox Strategy by SDLC Stage
A mature enterprise Salesforce SDLC uses multiple sandbox types in sequence:
- Development (DEV): Multiple Developer or Developer Pro sandboxes — one per developer or per feature stream. Developers work independently without stepping on each other's changes.
- Integration (INT): Partial Copy sandbox where feature branches are merged and tested together. Detects integration conflicts before UAT.
- UAT: Full Sandbox or well-configured Partial Copy where business stakeholders validate against realistic data. If performance testing is in scope, Full Sandbox is required.
- Staging / Pre-Production: Full Sandbox refreshed immediately before the production release to validate the deployment package. Catches last-mile issues (missing metadata, data-dependent logic) that earlier sandboxes might not surface.
Scratch Orgs in the Modern Pipeline
Scratch orgs are not sandboxes — they are temporary, source-driven environments created from SFDX project configuration. They are provisioned in minutes via the CLI, contain no production data, and expire after 1-30 days. They are the right tool for automated CI/CD pipelines because they are ephemeral, deterministic, and cheap.
The typical CI/CD pipeline with scratch orgs:
- Developer pushes a feature branch to Git.
- CI pipeline creates a new scratch org from the project's
project-scratch-def.json. - Deploy the branch's metadata to the scratch org.
- Run all Apex tests.
- Report results and delete the scratch org.
This gives every PR a clean, isolated test environment without consuming sandbox capacity or requiring human intervention.
# Create a scratch org for CI
sf org create scratch \
--definition-file config/project-scratch-def.json \
--set-default \
--alias ci-test-$BUILD_NUMBER \
--duration-days 1
# Deploy and test
sf project deploy start --target-org ci-test-$BUILD_NUMBER
sf apex run test --target-org ci-test-$BUILD_NUMBER --result-format human
# Delete after test
sf org delete scratch --target-org ci-test-$BUILD_NUMBER --no-promptData Masking and Compliance
Full and Partial Copy sandboxes contain real production data. For orgs in GDPR, HIPAA, or PCI scope, exposing production PII in sandbox environments creates compliance risk. Salesforce offers Data Mask as an add-on — it anonymises specified fields (names, email addresses, phone numbers, tax IDs) during the sandbox copy process.
If Data Mask is not available, three manual approaches:
- Post-copy Apex script: A scheduled Apex job that runs immediately after sandbox refresh and anonymises sensitive fields. Requires a one-time trigger in the sandbox.
- Partial Copy template design: Avoid including sensitive object types in the Partial Copy template entirely. Use fabricated test data instead.
- Sandbox seeding: Start from Developer Sandbox (no data) and load a purpose-built anonymised dataset via Data Loader or seed scripts.
Sandbox Licences and Count Planning
Sandbox counts are determined by your Salesforce edition and add-on purchases. Typical inclusions per edition:
- Professional: 1 Developer Sandbox
- Enterprise: 1 Full, 1 Partial Copy, unlimited Developer
- Unlimited: 1 Full, 5 Partial Copy, unlimited Developer
Additional sandboxes can be purchased. For large programmes with multiple release streams, the default allocation is often insufficient. Budget for additional Partial Copy sandboxes if running more than two concurrent release tracks.
Key Takeaways
- Developer sandboxes copy metadata only — free and fast. Full sandboxes copy everything — expensive and slow to refresh.
- Full sandbox minimum refresh interval is 29 days — plan your release cadence around this constraint.
- Scratch orgs are ephemeral, source-driven, and purpose-built for CI/CD — they are not a sandbox replacement but a complement.
- Full and Partial Copy sandboxes contain real production data — data masking is required for GDPR/HIPAA compliance.
- Reserve Full Sandboxes for performance testing and final UAT — Partial Copy is usually sufficient for integration testing.
- Budget for additional Partial Copy sandboxes when running multiple concurrent release tracks.
Check Your Understanding
1. Which sandbox type is the best fit for automated CI/CD pipelines that run on every PR?
2. Your team is on GDPR scope and just refreshed a Full Sandbox from production. What is the immediate compliance concern?
3. What is the minimum refresh interval for a Full Sandbox?
Discussion & Feedback