Development Environment
A Development Environment in Salesforce is any org used for building, testing, or experimenting with code, configuration, or data outside the production org that the business actually operates on.
Definition
A Development Environment in Salesforce is any org used for building, testing, or experimenting with code, configuration, or data outside the production org that the business actually operates on. The category covers Developer Edition orgs (free standalone learning and ISV environments), sandboxes spun from a production org (Developer, Developer Pro, Partial Copy, Full Copy), scratch orgs (temporary DX-provisioned orgs for source-tracked development), and Trailhead Playgrounds (Trailhead-spawned learning orgs). Each type has a different purpose, scale, and refresh cadence.
Development Environments exist because building directly in production is unsafe and disallowed by mature operational discipline. Bug-causing code, schema-breaking metadata, accidentally deleted records all happen during development; they happen in development environments without touching the data the business runs on. The right environment for the work depends on what the work is: ad-hoc proof-of-concept goes to a Developer Edition or scratch org, multi-developer collaboration goes to source-tracked sandboxes, integration testing goes to Partial Copy or Full Copy sandboxes, UAT goes to Full Copy.
Why the right Development Environment matters more than admins often think
The four main Development Environment types
Developer Edition: free standalone org, lives indefinitely with periodic login, suitable for individual learning and ISV development. Sandbox: spawned from production with metadata or metadata-plus-data depending on type, lives as long as the org subscribes. Scratch Org: temporary DX-provisioned org, lives 7 to 30 days, source-tracked, suitable for code-heavy development. Trailhead Playground: Trailhead-spawned learning org, lives as long as the Trailhead account, scoped for module work. Pick based on the work.
Sandbox tiers: Developer, Developer Pro, Partial Copy, Full Copy
Salesforce sandboxes come in four tiers. Developer (smallest, no data, metadata only, 1-day refresh interval) for individual development. Developer Pro (larger storage than Developer, no data, 1-day refresh) for multi-feature development. Partial Copy (metadata plus a configured subset of data via Sandbox Template, 5-day refresh) for integration testing with realistic data. Full Copy (metadata plus all production data, 29-day refresh) for UAT, performance testing, training. Each tier has different storage and refresh limits.
Scratch orgs and the source-tracked workflow
Scratch orgs are the developer-experience evolution of sandboxes. Spawned through Salesforce CLI from a Dev Hub, lives 7 to 30 days by default, configured by a scratch org definition file. Suitable for source-tracked development where the developer pushes metadata from local Git, tests, iterates, destroys the org when done. The pattern enables disposable orgs per feature branch; the cost is the maintenance of scratch org definition files and the Dev Hub configuration.
Refresh cadence and the data freshness question
Sandboxes refresh on a configurable cadence: Developer and Developer Pro can refresh daily, Partial Copy every 5 days, Full Copy every 29 days. Refresh resets the sandbox to a fresh copy of production metadata (and data for Partial/Full). Refresh is destructive of work done in the sandbox since the last refresh; coordinate before refreshing. Most teams plan sandbox refreshes around release cycles; Full Copy refreshes are particularly disruptive and require advance notice to UAT users.
Naming conventions and the environment-mapping discipline
Mature orgs name sandboxes per purpose: DEV (individual developer sandboxes), INT (integration testing), UAT (user acceptance testing), STAGE (pre-production), TRAIN (end-user training). The naming makes the environment-to-purpose mapping clear in change set source/target selection, in CI pipelines, in support tickets. Orgs without naming conventions end up with sandboxes named after the admin who created them; the lack of convention costs in operational clarity over years.
Promotion path and the change pipeline
Modern Salesforce orgs run a promotion pipeline: development in DEV sandboxes or scratch orgs, integration in INT, user testing in UAT, pre-production validation in STAGE, deploy to production. Each promotion is a deployment (Change Set, DevOps Center, or third-party tool); the pipeline produces the audit trail for production changes. Smaller orgs collapse the pipeline; enterprise orgs run the full pipeline with multiple gates.
Cost and the sandbox quota question
Sandboxes consume against the org's sandbox quota per the edition. Enterprise Edition includes a small number of each tier; additional sandboxes are paid. Full Copy sandboxes are expensive (typically thousands per year each). Most orgs budget sandbox quota deliberately: one Full Copy for UAT, one or two Partial Copies for integration, multiple Developer Pros for individual developers, ad-hoc Developer sandboxes for short-lived work.
How to pick the right Development Environment for the work
The pattern: match the environment to the work, name per convention, refresh deliberately, promote through the pipeline. The discipline pays back in operational clarity and reduced production incidents over years.
- Identify the work scope and required fidelity
Individual learning: Developer Edition or Trailhead Playground. Code dev: scratch or Developer sandbox. Integration testing: Partial Copy. UAT or performance testing: Full Copy.
- Check sandbox quota in Setup, Company Information
Confirm the org has the sandbox tier available before assuming you can spin one.
- Create the environment with a convention-based name
DEV-feature-name, INT, UAT, STAGE-2026Q1. The name carries purpose.
- Apply the Sandbox Template for Partial Copy
Partial Copy uses a Sandbox Template to scope which data subset to copy.
- Establish the promotion path through Change Sets or DevOps Center
The path from DEV to production drives the deployment workflow.
- Schedule refreshes around release cycles
Full Copy refresh is disruptive; schedule for between releases and communicate to UAT users.
- Retire unused environments to reclaim quota
Sandboxes accumulate. Quarterly audit identifies retirement candidates.
Developer Edition, Developer/Developer Pro/Partial Copy/Full Copy sandbox, Scratch Org, Trailhead Playground.
Purpose-driven naming (DEV, INT, UAT, STAGE) drives operational clarity.
Per-tier refresh interval; plan around release cycles.
Configuration for Partial Copy sandbox data subset.
Documented flow from DEV through INT, UAT, STAGE, production.
- Full Copy sandboxes are expensive. Budget deliberately; one Full Copy is usually enough for UAT.
- Sandbox refresh is destructive of in-sandbox work. Coordinate before refreshing.
- Scratch orgs require Dev Hub configuration. The setup is one-time; ongoing scratch org lifecycle is automated through CLI.
- Naming conventions are easy to skip and impossible to retrofit cleanly. Establish at the first sandbox creation.
- Stale unused sandboxes consume quota. Quarterly retirement audit keeps quota available for active work.
Trust & references
Cross-checked against the following references.
- Sandbox referenceSalesforce
- Salesforce DevelopersSalesforce
Straight from the source - Salesforce's reference material on Development Environment.
- SandboxesSalesforce Help
- Scratch OrgsSalesforce Developers
- Developer EditionSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What counts as a Development Environment?
Q2. Why use development environments?
Q3. What's the modern environment type for ephemeral feature work?
Discussion
Loading discussion…