Introduction
A Salesforce Sandbox is an isolated copy of your production Salesforce org used for development, testing, training, and integration. Sandboxes let teams build and validate changes without risking production data or business processes. This post explains what a sandbox is, the different sandbox types available in Salesforce, their use cases, limits, and best practices.
What is a Salesforce Sandbox?
In simple terms, a Sandbox is a safe replica of your Salesforce environment. Depending on the sandbox type, it can contain just metadata (configuration, code, and setup) or both metadata and production data. Sandboxes are essential for change management, release cycles, QA, user training, and testing integrations.
Key terms
Metadata: Objects, fields, Apex, Visualforce, Lightning components, flows, permissions, and configuration.
Data: Records like Accounts, Contacts, Opportunities, and custom object records.
Refresh interval: How often a sandbox can be refreshed from production.
Types of Sandboxes
Salesforce provides four main types of sandboxes. Each type serves different purposes and has different storage and refresh limits.
1. Developer Sandbox
Designed for individual developers or small development tasks.
- Contents: Metadata only (no production data).
- Storage: Small, intended for code and configuration.
- Refresh interval: Typically 1 day.
- Use cases: Build Apex classes, Lightning components, or configuration changes that don’t require production data for testing.
2. Developer Pro Sandbox
An enhanced Developer sandbox with more storage.
- Contents: Metadata only (no production data).
- Storage: Larger than Developer Sandbox — supports bigger codebases and some test data.
- Refresh interval: Typically 1 day.
- Use cases: Development requiring additional storage for test records or more complex code and configuration testing.
3. Partial Copy Sandbox
Balances data and speed — useful for testing with a subset of production data.
- Contents: Metadata + a sample of production data (selected via a sandbox template).
- Storage: Limited; only a subset of records defined by the template are copied.
- Refresh interval: Usually 5 days.
- Use cases: QA testing, integration tests, user acceptance testing (UAT) where realistic but limited data is needed.
- Setup note: Create a Sandbox Template in Setup to select which objects and data to copy.
4. Full Sandbox
The most complete copy — mirrors production metadata and data.
- Contents: Full copy of production (all metadata and data).
- Storage: Same as production since it’s a complete clone.
- Refresh interval: Longer (typically 29 days), varies by Salesforce edition and license.
- Use cases: Performance testing, load testing, full end-to-end QA, training with realistic data, and pre-production validation.
- Consideration: Creating and refreshing Full Sandboxes can be time-consuming and may require coordination with stakeholders.
Other sandbox-related concepts
Sandbox Templates: For Partial Copy sandboxes, templates define which objects’ data to include. Use templates to avoid copying unnecessary or sensitive records.
Data Masking & Anonymization: When copying production data to a sandbox, consider masking or anonymizing sensitive fields (PII) to maintain compliance with privacy rules.
When to use which sandbox?
- Quick code changes, experiments: Developer or Developer Pro.
- Integration and UAT with realistic sample data: Partial Copy.
- Full-scale testing, training, or performance validation: Full Sandbox.
Best practices
- Use version control for all metadata and deployments (CI/CD) rather than relying on Sandboxes as the single source of truth.
- Keep sandbox refresh schedules documented and notify teams prior to refreshes.
- Mask or remove sensitive data before copying to sandboxes, especially Partial and Full sandboxes.
- Use sandbox templates to limit unnecessary data copies and shorten sandbox build times.
- Automate deployments using change sets, Salesforce CLI, or a CI/CD pipeline to ensure consistent deployments between environments.
Quick commands and examples
If you use Salesforce CLI (sfdx) for deployments, you can create and deploy to a sandbox-connected org. Example: authorize a sandbox and deploy metadata.
sfdx force:auth:web:login -r https://test.salesforce.com -a MySandbox
sfdx force:source:deploy -u MySandbox -p force-app/main/default
Conclusion
Sandboxes are a critical part of a robust Salesforce development lifecycle. Choosing the right sandbox type depends on your testing and development needs — Developer and Developer Pro for coding and configuration, Partial Copy for realistic subset testing, and Full for end-to-end validation. Follow best practices around refresh policies, data protection, and CI/CD to get the most value from your sandboxes.