Definition
Sandboxes is a Setup page that displays all sandbox environments associated with the org and provides tools to create, refresh, clone, and manage them. Administrators can view each sandbox's type (Developer, Developer Pro, Partial Copy, Full), status, last refresh date, and available actions.
Real-World Example
The admin at CloudSync opens the Sandboxes page and sees four environments: a Developer sandbox for daily development, a Developer Pro sandbox for integration testing, a Partial Copy sandbox for UAT with a subset of production data, and a Full sandbox for final staging. She refreshes the UAT sandbox with the latest production data before the next release cycle.
Why Sandboxes Matters
The Sandboxes page in Salesforce Setup is the central management interface where administrators view, create, refresh, clone, and manage all sandbox environments associated with the production org. The page displays each sandbox's name, type (Developer, Developer Pro, Partial Copy, Full), current status (Active, Pending, Deleted), last refresh date, and available actions. Administrators can initiate sandbox creation by selecting the type and optionally assigning a Sandbox Template for Partial Copy types. The refresh action replaces the sandbox's metadata and data with a current copy from production, while the clone action creates a new sandbox from an existing one—useful for creating identical test environments without consuming a production refresh.
As release management processes mature, organizations accumulate multiple sandboxes serving different purposes—development, integration testing, UAT, training, and staging. The Sandboxes page provides the operational visibility needed to manage this environment landscape effectively. Without centralized management, administrators lose track of when sandboxes were last refreshed (leading to testing against stale metadata), create sandboxes that exceed their license allocation, or fail to coordinate refresh timing with development teams who have unsaved work. Best practice dictates checking the Sandboxes page before every release cycle to ensure testing environments are refreshed with current production metadata, and maintaining a documented schedule so teams know when their sandbox will be refreshed and can plan accordingly.
How Organizations Use Sandboxes
- CloudSync Engineering — CloudSync's admin opens the Sandboxes page and manages four environments: a Developer sandbox refreshed weekly for daily development, a Developer Pro for integration testing refreshed biweekly, a Partial Copy for UAT with a subset of production data refreshed before each sprint, and a Full sandbox for final staging refreshed quarterly. The page's status indicators help her confirm all environments are active before each release cycle begins.
- Nexus Release Management — Nexus Release Management uses the Sandboxes page to coordinate refresh timing across 8 teams. Before each monthly release, the release manager checks last refresh dates to ensure all QA sandboxes have current metadata. She discovered that one team's sandbox hadn't been refreshed in 4 months, meaning they were testing against outdated metadata—a potential source of deployment failures.
- Pinnacle DevOps Team — Pinnacle DevOps uses the clone feature from the Sandboxes page to create identical environments for parallel testing. When two development teams need to test against the same baseline, they clone the UAT sandbox rather than refreshing twice—saving the refresh allocation and ensuring both teams start from identical configurations. This approach saved them 3 refresh cycles per quarter.