Advanced 25 min read

Scratch Orgs

By the end of this lesson, you'll be able to:

  • Explain what a scratch org is and how it differs from a traditional sandbox
  • Recognize the disposable, source-driven nature of scratch orgs
  • Understand why this fits naturally with Module 14's branching workflow

Prerequisites: "What Is Salesforce DX?"

Disposable, not persistent

A traditional sandbox is a long-lived copy of production, manually maintained over time. A scratch org is deliberately temporary — created fresh from source-controlled metadata in minutes, used for a specific piece of work, then deleted entirely once that work is done. Nothing about it is meant to persist.

Created entirely from source

sf org create scratch --definition-file config/project-scratch-def.json --alias my-feature-org
sf project deploy start --target-org my-feature-org
  1. sf org create scratch --definition-file config/project-scratch-def.json --alias my-feature-org — creates a fresh org from the source-controlled definition file, given a memorable local alias.
  2. sf project deploy start --target-org my-feature-org — deploys the project's actual metadata into that newly created org.

A scratch org's configuration (project-scratch-def.json) and its actual metadata both come from source-controlled files — this is the direct, practical consequence of Module 40's opening lesson: the org is generated from code, not the other way around.

Why this fits Module 14's branching workflow naturally

git checkout -b feature/loyalty-discount
sf org create scratch --alias loyalty-feature-org
# develop and test entirely in this disposable org
git push origin feature/loyalty-discount
sf org delete scratch --target-org loyalty-feature-org
  1. git checkout -b feature/loyalty-discount — Module 14's branching pattern — a new branch for one feature.
  2. sf org create scratch --alias loyalty-feature-org — a dedicated, disposable org for this branch alone.
  3. # develop and test entirely in this disposable org — a comment marking where the actual work happens.
  4. git push origin feature/loyalty-discount — the code changes, pushed as usual.
  5. sf org delete scratch --target-org loyalty-feature-org — the org itself, discarded once the work is done.

One scratch org per feature branch (Module 14's branching pattern) means a developer's in-progress work is fully isolated — not just at the code level, but at the actual Salesforce environment level too — with zero risk of one feature's half-finished configuration leaking into another's testing.

Exercise

As a comment, explain why a scratch org is well suited to Module 14's "one feature, one branch" workflow specifically.

Show hint

Think about what a persistent, shared sandbox would risk instead.

APEX

Scratch Orgs Quiz

1. What is the key difference between a scratch org and a traditional sandbox?

Log in to submit the quiz and save your score.

My Notes

Log in to keep private notes on this lesson.

Questions about this lesson

No questions yet — be the first to ask.

Log in to ask a question about this lesson.

Summary

A scratch org is a temporary, disposable Salesforce environment created entirely from source — the natural environment for developing and testing one specific branch of work.