Introduction
In Salesforce, a sandbox is a copy of your production org used for development, testing, training, and QA without impacting live data or users. Sandboxes help teams safely build and validate changes before deploying them to production, reducing risk and improving release quality.
Why use a Sandbox?
Sandboxes provide isolated environments where administrators and developers can:
– Build and test new features
– Validate integrations and data migrations
– Train users on workflows without affecting production
Types of Sandboxes in Salesforce
Salesforce provides several sandbox types tailored to different use cases and data needs. The main sandbox types are:
1) Developer Sandbox
A Developer Sandbox is a lightweight environment intended for individual developers. It includes a copy of your production configuration (metadata) but contains minimal or no production data.
Key points:
– Use case: Development, unit testing, building metadata changes
– Storage: Small file and data storage limits
– Data: No production data copied by default (you can load sample/test data)
– Refresh interval: Typically can be refreshed once per day
2) Developer Pro Sandbox
Developer Pro is similar to the Developer sandbox but with larger storage limits, making it better for more complex development and integration testing.
Key points:
– Use case: Development and more extensive testing that needs greater data capacity
– Storage: Larger file and data storage than Developer
– Data: Metadata copy only; data must be loaded as needed
– Refresh interval: Often daily
3) Partial Copy Sandbox
Partial Copy includes all metadata and a sample of production data defined by a sandbox template. It’s useful for functional testing with a limited dataset.
Key points:
– Use case: QA, UAT, and testing processes that require representative data
– Storage/Data: Includes sample data (up to a quota) based on a defined template
– Refresh interval: Usually once every 5 days (varies by edition)
4) Full Sandbox
A Full Sandbox is a complete copy of your production environment — including metadata, all data, attachments, and a complete replica of configuration and customizations. It’s ideal for performance, load testing, and final-stage UAT.
Key points:
– Use case: Performance testing, full-scale QA, and staging for deployments
– Storage/Data: Full copy of production data and configuration
– Refresh interval: Longer refresh intervals (e.g., 29 days); limited number of Full sandboxes per org
Comparing Sandboxes at a Glance
Developer: Metadata only, small storage, daily refresh — best for individual development.
Developer Pro: Metadata only, larger storage — good for heavier development and integration testing.
Partial Copy: Metadata + sample data via templates — suitable for QA/UAT with representative data.
Full: Complete copy of production — required for performance and end-to-end testing.
Best Practices and Considerations
– Choose the sandbox type based on testing needs: use Developer/Developer Pro for development, Partial Copy for functional testing, and Full for performance and final validation.
– Manage refresh schedules: Coordinate refreshes to minimize downtime for teams and ensure testers are using current data.
– Mask or anonymize sensitive data in sandboxes to comply with privacy and security policies (Salesforce provides tools and strategies for data masking).
– Keep deployment pipeline streamlined: Use change sets, Salesforce CLI, or CI/CD tools to move metadata from sandboxes to production.
Conclusion
Sandboxes are essential for safe, structured development and testing in Salesforce. Understanding the differences between Developer, Developer Pro, Partial Copy, and Full sandboxes helps teams select the right environment for each stage of development and testing, ensuring quality releases with minimal risk to production.