Salesforce DictionarySalesforce DictionarySalesforce DictionarySalesforce DictionaryPersistent copy vs disposable development environment
A Sandbox is a separate Salesforce environment that copies the metadata (and optionally the data) from a production org for development, testing, training, or staging purposes. Every nontrivial Salesforce project uses sandboxes: developers build in one, QA tests in another, training happens in a third, and a final staging sandbox mirrors production for pre-deployment validation. Sandboxes prevent the catastrophic mistakes that would otherwise happen if every change had to be made directly in production. Salesforce offers four sandbox types, each tuned for a different stage of the development lifecycle. Developer sandboxes are smallest (200 MB data, refresh daily), best for individual feature work. Developer Pro sandboxes are larger (1 GB data, refresh daily), good for integration testing. Partial Copy sandboxes include a configurable subset of production data (5 GB), useful for UAT with realistic data. Full Copy sandboxes are a complete production replica including all data (matched storage), refresh every 29 days, and are the standard for staging environments. Each type has different storage allotments and refresh intervals that shape how teams use them.
A Scratch Org is a temporary, source-driven Salesforce environment created on demand from a project's source code via the Salesforce CLI. It is the cornerstone of the Salesforce DX development model: spin up a fresh org, push the latest project source, run tests, then discard it. Scratch orgs live up to 30 days (configurable per definition file), are billed against a Dev Hub allocation rather than per-edition licenses, and start empty rather than copying production metadata or data. Scratch orgs solve problems that traditional Developer sandboxes cannot. Each scratch org represents a clean state, so developers test their feature against a known starting point rather than against the accumulated drift of a shared sandbox. The org definition file (.json) declares which features, settings, and edition to include, so the org matches exactly what production needs. Continuous Integration pipelines spin up scratch orgs to run automated tests, validate metadata, and tear them down within minutes. Scratch orgs are the standard for source-driven Salesforce development; legacy projects on older workflows often have not adopted them yet.
| Dimension | Sandbox | Scratch Org |
|---|---|---|
| Data | Can include production data (Full/Partial) | Starts empty - no production data |
| Lifespan | Persistent - lasts until refreshed or deleted | Temporary - expires in 1 to 30 days |
| Configuration | Copy of production metadata and optional data | Defined via scratch org definition file (JSON) |
| Source Control | Manual deployment or change sets | Native Salesforce DX and source-driven development |
| Use Case | UAT, staging, training, integration testing | Feature development, CI/CD, automated testing |
UAT, staging, training, or integration testing with production-like data.
Feature development, CI/CD pipelines, and disposable dev environments.