Development Environment
A development environment in Salesforce is any org used for building, testing, or experimenting with code, configuration, or data away from the production org that the business actually runs on.
Definition
A development environment in Salesforce is any org used for building, testing, or experimenting with code, configuration, or data away from the production org that the business actually runs on. The category groups several distinct org types. Developer Edition orgs are free standalone orgs for individual learning and ISV work. Sandboxes are copies spun from a production org. Scratch orgs are short-lived orgs provisioned through Salesforce DX. Trailhead Playgrounds are learning orgs created from Trailhead. Each type has its own purpose, size, and refresh behavior.
These environments exist because building directly in production is risky and goes against sound operational practice. Bugs in new code, schema changes that break existing automation, and accidentally deleted records all happen while people work. In a development environment they happen without touching live business data. The right choice depends on the task. A quick proof of concept fits a Developer Edition or scratch org. Multi-developer work fits source-tracked sandboxes or scratch orgs. Integration testing with realistic data fits a Partial Copy or Full sandbox, and user acceptance testing usually needs a Full sandbox.
Picking the right org for the work in front of you
The four kinds of development org
Salesforce gives you four broad options, and they suit different jobs. A Developer Edition org is free and stands on its own. It lives indefinitely as long as you log in periodically, and it carries reduced limits, which makes it ideal for personal learning and for building managed packages as an ISV partner. A sandbox is a copy made from a production org, so it inherits your real configuration and, depending on the type, some or all of your data. A scratch org is a temporary org created through the Salesforce CLI, source-tracked by design, and meant to be thrown away when the work is done. A Trailhead Playground is a small org spawned from your Trailhead account that you use to complete hands-on challenges. The simplest way to choose is to ask what the work needs. Learning a feature points to a Playground or Developer Edition. Writing and version-controlling code points to a scratch org. Testing against production-shaped configuration and data points to a sandbox.
Sandbox tiers and their refresh windows
Sandboxes come in four tiers, and the differences matter for both cost and capability. A Developer sandbox copies metadata only, with no production data, gives you 200 MB of data storage, and can be refreshed once a day. A Developer Pro sandbox is the same idea with more room, 1 GB of data storage, also refreshable daily, which suits work that needs a small set of test records. A Partial Copy sandbox includes metadata plus a sample of production data defined by a sandbox template, offers 5 GB of data storage, and can be refreshed every 5 days. That makes it a good fit for integration testing where realistic but not complete data is enough. A Full sandbox copies metadata and all of your production data, matches your production storage, and can be refreshed every 29 days. Because it mirrors production most closely, teams reserve it for user acceptance testing, performance testing, and end-user training. The refresh interval is the minimum wait between refreshes, so plan around it.
Scratch orgs and source-tracked development
Scratch orgs are the Salesforce DX answer to disposable, code-first development. You create one from the command line against a Dev Hub, which is the main org that authorizes and tracks scratch org creation. A scratch org definition file describes the shape of the org, including its edition and which features and settings are enabled, so every developer can spin up an identical environment on demand. By default a scratch org lasts 7 days, and you can extend that up to 30 days using the duration-days option when you create it. Source tracking is the part that makes the workflow pay off. The CLI watches the difference between your local project and the org, so when you change metadata in either place it knows what moved. You push your source from Git into a fresh org, build and test, then delete the org. There is no package.xml to hand-maintain for these changes. The trade-off is upkeep of the definition file and the Dev Hub, plus the discipline of keeping source in version control as the single source of truth.
Refresh, and why it is destructive
Refreshing a sandbox resets it to a fresh copy of production. For Developer and Developer Pro that means current metadata only. For Partial Copy it means metadata plus a new sample of data, and for Full it means metadata plus a complete copy of production data. The important point is that a refresh wipes out anything created in the sandbox since the last refresh. Unsaved configuration, half-finished features, and loaded test data all disappear unless they have been deployed out or backed up first. That is why refresh cadence needs coordination rather than a casual click. Most teams line their refreshes up with release cycles so a sandbox starts each cycle matching production. Full sandbox refreshes deserve extra care because the org is usually shared by testers and trainers. A surprise refresh during a user acceptance testing window can erase test progress and force a restart. Give advance notice, confirm nobody has unsaved work, and treat the refresh as a planned event with an owner.
Naming conventions and the promotion path
Once an org has more than one or two sandboxes, naming them by purpose pays off. Common labels are DEV for individual developer orgs, INT for integration testing, UAT for user acceptance testing, STAGE for pre-production validation, and TRAIN for end-user training. The names make the environment-to-purpose mapping obvious when you pick a source and target for a change set, wire up a CI pipeline, or read a support ticket. Orgs without a convention drift toward sandboxes named after whoever created them, and that vagueness costs time for years. The naming supports a promotion path, which is the route a change takes from first build to production. A typical flow moves work from a DEV sandbox or scratch org into INT, then UAT, then STAGE, then production. Each hop is a deployment, run through change sets, DevOps Center, or a third-party DevOps tool, and each deployment leaves an audit record. Smaller orgs collapse some of these stages, while larger ones add gates and approvals at each step.
Quota, cost, and keeping environments tidy
Sandboxes are not unlimited. Each edition includes a set allotment of each tier, and anything beyond that allotment is a paid add-on. Developer and Developer Pro sandboxes are relatively cheap and plentiful. Partial Copy and especially Full sandboxes are more expensive, and a Full sandbox can run into the thousands of dollars per year. Because of that, teams budget their quota on purpose rather than spinning up sandboxes freely. A common shape is one Full sandbox for user acceptance testing, one or two Partial Copies for integration work, several Developer Pro sandboxes for individual developers, and short-lived Developer sandboxes for quick tasks. Scratch orgs help here too, since they cost nothing extra against the sandbox quota and disappear on their own. The maintenance habit that keeps this healthy is periodic cleanup. Review your sandboxes on a regular schedule, delete the ones nobody uses, and reclaim the quota for work that needs it. Letting stale sandboxes pile up quietly blocks the environments your active projects depend on.
How to create a sandbox in Setup
Sandboxes are created and refreshed from Setup in the production org, by an admin with the Manage Sandbox permission. Here is the path to create one.
- Open Sandboxes in Setup
In your production org, go to Setup and enter Sandboxes in the Quick Find box. Open the Sandboxes page to see your existing sandboxes and your remaining allotment by type.
- Start a new sandbox
Click New Sandbox. Give it a name (keep it short, since the name becomes part of the org login) and a description that states its purpose, such as INT or UAT.
- Choose the type
Select Developer, Developer Pro, Partial Copy, or Full based on the work. Partial Copy and Full also let you attach a sandbox template to control which objects and data are copied.
- Create and wait
Submit the request. Salesforce queues the copy, and the time to finish depends on the type and how much data is involved. You get an email when the sandbox is ready to log in.
A short identifier appended to your org login. Plan it around a naming convention like DEV, INT, UAT, or STAGE.
Developer or Developer Pro for metadata-only work, Partial Copy for sample data, Full for a complete production copy.
For Partial Copy and Full, an optional template that selects which objects and records are copied so you control size and scope.
An optional post-copy Apex class that runs after creation or refresh, useful for masking data or resetting environment-specific settings.
- Refresh is destructive. Anything built in the sandbox since the last refresh is lost, so deploy or back it up first.
- Refresh intervals are minimums: 1 day for Developer and Developer Pro, 5 days for Partial Copy, 29 days for Full.
- Full sandboxes are costly and limited in number, so reserve them for UAT, performance testing, and training.
- Sandbox copies are not instant. Full sandboxes in particular can take hours, so plan creation ahead of any deadline.
Prefer this walkthrough as its own page? How to Development Environment in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Development Environment.
- Sandbox Types and TemplatesSalesforce
- Select and Enable a Dev Hub OrgSalesforce
Hands-on resources to go deeper on Development Environment.
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. Which org types count as Development Environments in a Salesforce program?
Q2. Which Development Environment is the source-tracked, ephemeral choice for per-feature work in DX?
Q3. Among Development Environment sandbox tiers, which offers the longest refresh interval and full data for UAT?
Discussion
Loading discussion…