Salesforce DX: Scratch Orgs vs Sandboxes in a Real ALM Setup

Quick Answer: Salesforce DX scratch orgs vs sandboxes is a false choice: scratch orgs are disposable, source-driven environments you create from a definition file for feature work and CI, then delete; sandboxes are long-lived copies of an org — with real data in the fuller editions — that exist for integration testing, UAT and release rehearsal. Most mature Indian teams run both: scratch orgs in the pipeline, a sandbox where humans test.

Salesforce DX Scratch Orgs vs Sandboxes: Different Problems, Different Orgs

The comparison is usually framed as a choice. It is not — but you need the differences on the table before the hybrid setup makes sense.

Two honest caveats. Scratch orgs give you no data, so any test that needs a realistic volume — a batch job, a report against a year of history — needs seeding, and seeding well is its own skill. And sandbox source tracking is uneven: newer source-tracked sandboxes exist, but plenty of Indian teams still run classic sandboxes where someone edits directly in the org. That last habit is where most release pain comes from, as the war story below makes concrete.

The Source Model Behind the Scratch Org

Scratch orgs only make sense once you accept that the repository — not the org — is the project. The anchor file:

{
  "packageDirectories": [
    { "path": "force-app", "default": true }
  ],
  "name": "skilbrill-ecs",
  "sfdcLoginUrl": "https://login.salesforce.com",
  "sourceApiVersion": "64.0"
}

Everything about your workflow follows from that file. force-app is where metadata lives as files; the definition file for your scratch org (a project-scratch-def.json naming the edition, features and settings) sits beside it, which means an environment is now something you can review in a pull request rather than something a person built by clicking. Two people can create byte-identical orgs from the same commit — that property is the entire value proposition, and it is what makes CI possible at all.

The CLI Workflow, With Real Commands

The modern Salesforce CLI (sf) has superseded the older sfdx commands, and most teams still meet both. The scratch lifecycle first:

# create a disposable org from the definition file, valid 7 days
sf org create scratch -f config/project-scratch-def.json -a dev-jaya -d -y 7

# deploy your branch, then run the test suite with coverage
sf project deploy start -d force-app -o dev-jaya
sf apex run test -l RunLocalTests -c -r human -w 10 -o dev-jaya

# pull back what you changed (or what a merge produced)
sf project retrieve start -o uat -d force-app

# check and destroy — burning it down is part of the model
sf org display -o dev-jaya
sf org delete scratch -o dev-jaya -p

The legacy equivalents still appear in older pipelines and interview questions: sfdx force:org:create -f config/project-scratch-def.json -a dev -s -d7, sfdx force:source:push -u dev, sfdx force:apex:test:run -l RunLocalTests -c -r human -w 10 -u dev, and sfdx force:source:retrieve -u uat -p force-app. Knowing both is worth a small amount of money in interviews and a larger amount on a team that has not finished migrating.

Sandbox creation moves with CLI versions — flags have been renamed more than once — so rather than print a command that may not match your installed version, run sf org create sandbox --help and use the current long-form flags. The workflow around it is stable regardless: create from the production org as the login org, pick the edition deliberately, wait for the refresh, then reset users, data loads and any non-replicated settings. Sandboxes are also where people meet their first surprise about what does and does not copy — email templates, some settings and all users need attention after every refresh.

How Teams Actually Combine the Two

The progression is the point: scratch orgs answer “does the code work?”, sandboxes answer “does the change work here, with this data, for these people?” Teams that try to answer the second question with scratch orgs end up seeding synthetic data forever; teams that answer the first question with a shared sandbox end up with an environment nobody trusts. Deploying the same change safely into the shared instances is a related discipline — the mechanics of promoting configuration without losing someone else’s work are covered in the update set promotion guide on the ServiceNow side, and the same thinking applies.

What Actually Happens at Work

A mid-size retail company ran two Developer Pro sandboxes: INT and UAT. INT was deployed from source. UAT was, by long tradition, configured by hand — “we’ll tidy it up before release”. Three weeks before a major release, three admins worked in UAT over two days, adding a record type, tweaking two flows and building the approval path the business had signed off on in a spreadsheet.

On Thursday someone refreshed UAT to get clean data for a demo. All three days of work vanished. Not corrupted — gone, because UAT was not source-tracked and nothing had been retrieved into Git. The rebuild took most of a week, and the release slipped, in a company where the release window was quarterly and missing it meant waiting three months.

The fix was process, not tooling. Every shared org became source-tracked or, where that was impractical, every change went through a scratch org first and was retrieved into the repo — a rule that felt bureaucratic for a month and then felt obvious. UAT refreshes were scheduled and announced, with a hard rule that nothing lives only in an org. And the pipeline’s habit of destroying its scratch orgs after every build turned out to be the cultural lesson the team most needed: environments are cattle, because the day you treat one as precious is the day its loss becomes an incident. For the release side of this — what your CI should run and when — the runtime question of Apex vs LWC is a separate one, and the pay attached to owning this workflow properly sits in the Salesforce developer salary guide.

Costs and Limits Worth Knowing

Scratch orgs are “free” in the sense that they come with a Dev Hub and limited by daily creation quotas — quotas that bite hardest on shared Dev Hubs, where one enthusiastic pipeline can exhaust the day for everyone. Sandboxes are licensed per org by edition, so the usual Indian SI pattern — one Full for UAT, a couple of Developer Pro for integration, Developer editions for individuals — is a budgeting decision as much as a technical one. Refresh time scales with size: a Full sandbox refresh is measured in hours, which is why refreshes are scheduled events rather than something you do because you wanted clean data this afternoon.

Training Resources

ALM habits are best learned inside a real pipeline rather than from a diagram. SkilBrill Salesforce Developer Training covers Salesforce DX, source-tracked development, testing and deployment practice alongside Apex and LWC, with career support and placement assistance.

FAQ

What is the difference between a scratch org and a sandbox in Salesforce DX?

A scratch org is a disposable, source-defined environment for feature work and CI, created from a definition file and deleted when done. A sandbox is a long-lived copy of another org — with data in the fuller editions — used for integration, UAT and release rehearsal.

Should I use scratch orgs or sandboxes for UAT?

Sandboxes. UAT needs realistic data, persistence and shared access for business users; scratch orgs start empty and expire in days. Use scratch orgs for development and automated testing instead.

Do scratch orgs have source tracking?

Yes — that is their design: source lives in Git and you push and retrieve against it. Classic sandboxes usually do not, which is why direct edits in a sandbox are the most common way work gets lost.

How long does a scratch org last?

Seven days by default, extendable up to thirty. Treat expiry as normal: your source should be in Git, so destroying an org should cost you only the re-creation time.

Can I run a Salesforce CI pipeline without scratch orgs?

Yes — some teams deploy into a dedicated sandbox for every build. Scratch orgs are cleaner because each build starts from a pristine baseline defined in code, but the discipline matters more than the org type.

Written by SkilBrill Training Institute

October 15, 2026 · 8 min read