Overview
A Salesforce Sandbox is a copy of your production Salesforce environment used for development, testing, training, and quality assurance without affecting live data or users. Sandboxes enable admins and developers to safely build and test changes—configuration, code, integrations—before deploying to production. They copy metadata and, depending on the sandbox type, a subset or full copy of production data.
Why use Sandboxes?
Sandboxes provide an isolated, risk-free environment to:
– Develop and test Apex, Lightning Components, Flows, and configurations.
– Validate integrations and CI/CD pipelines.
– Perform user training and UAT (User Acceptance Testing).
– Reproduce and debug production issues with comparable metadata and data.
Types of Sandboxes in Salesforce
Salesforce offers four primary sandbox types. Each serves different needs based on data volume, refresh frequency, and testing requirements.
Developer Sandbox
Ideal for individual developers:
– Copies: Metadata only (no production data).
– Use case: Building and unit-testing code, configuration changes, and small integrations.
– Storage & limits: Small storage suitable for metadata and limited test records.
– Refresh interval: 1 day.
Developer Pro Sandbox
For slightly larger development and integration tests:
– Copies: Metadata only, but with higher storage limits than Developer Sandbox.
– Use case: Team development, larger test data sets, and integration testing that needs more storage.
– Storage & limits: More storage than Developer Sandbox, but still limited compared to Partial Copy/Full.
– Refresh interval: 1 day.
Partial Copy Sandbox
For testing with representative sample data:
– Copies: Metadata + a subset of production data defined by a Sandbox Template. You can include selected objects and related records (up to the org’s Partial Copy data limit).
– Use case: QA, integration testing, and UAT where realistic sample data is required but a full copy is unnecessary.
– Storage & limits: Limited data storage (example: typically ~5GB, varies by edition).
– Refresh interval: 5 days.
Full Sandbox
The most complete environment—mirror of production:
– Copies: Metadata + full production data (all records, attachments, documents, and setup data), depending on storage and org limits.
– Use case: Final-stage testing, performance/load testing, training with real data, and full regression testing before deployment.
– Storage & limits: Matches production org’s data storage limits for the copied data; may take longer to refresh and can be limited by available storage and sandbox licenses.
– Refresh interval: 29 days (may vary by org/edition).
Sandbox Templates
Partial Copy Sandboxes use Sandbox Templates to select which objects and related data to copy. Templates let you include only the data needed for testing, reducing storage and masking sensitive data.
Refresh Intervals & Considerations
Each sandbox type has a minimum refresh interval—the time you must wait before re-creating or refreshing the sandbox:
Developer / Developer Pro: 1 day
Partial Copy: 5 days
Full Sandbox: ~29 days
Refresh operations copy metadata and data (as applicable) from production to the sandbox, so plan refreshes around release windows and integration schedules.
Best Practices
– Choose the smallest sandbox that meets your needs to reduce cost and speed up refresh times.
– Use sandbox templates to limit sensitive or irrelevant data when creating Partial Copy sandboxes.
– Anonymize or mask sensitive data in sandboxes if production data is copied.
– Automate setup steps (post-refresh scripts or deployment pipelines) to ensure sandboxes are production-like quickly after refresh.
– Keep track of sandbox-specific integrations and credentials—use named credentials or environment variables to avoid accidental calls to production services from sandboxes.
Common Use Cases
– Developer Sandbox: Build and unit-test new Apex classes or Lightning Components.
– Developer Pro: Team development and integration testing requiring more test records.
– Partial Copy: QA and UAT with realistic sample datasets for feature testing.
– Full Sandbox: Performance testing, full regression testing, and user training on production-like data.
Conclusion
Understanding the differences between Salesforce sandbox types ensures you pick the right environment for development, testing, and training. Selecting the appropriate sandbox reduces risk, speeds up delivery, and helps maintain production stability.