15.3 Sandboxes, Scratch Orgs & Environment Strategy

15.3 Sandboxes, Scratch Orgs & Environment Strategy

Quick Answer: Use sandboxes (Developer, Developer Pro, Partial Copy, Full) and/or scratch orgs to build and test away from production. Scratch orgs are disposable, defined by source/DX config; sandboxes copy metadata (and sometimes data) from production. Promote dev → test → staging/UAT → prod, keep metadata in Git, and manage data with templates, seeds, and masking—not by coding first in production.

Environment strategy is how professional Salesforce teams avoid “it worked in my org” disasters. Platform Developer I expects you to know sandbox types, what scratch orgs are for, and how source-driven development changes the old “everything lives only in the org” model.

Why Multiple Environments Exist

Production holds real customers, real automations, and real compliance constraints. Development needs freedom to break things. Testing needs repeatability. UAT needs business-realistic paths. Those forces produce a pipeline of environments with different data, users, and change rules.

Sandbox Types

Salesforce sandboxes are copies derived from production (metadata always; data depending on type). Refresh intervals and storage differ by type and license—exam items focus on purpose and data, not memorizing every storage megabyte table from a specific edition.

Developer Sandbox

• Metadata: Yes (configuration/code from source org at creation/refresh).
• Data: Minimal/sample—not a full production dataset.
• Best for: Individual developers building features, unit testing, early configuration.
• Traits: Relatively quick to create/refresh compared with Full; limited data and storage versus larger types.

Developer Pro Sandbox

• Same idea as Developer—metadata-focused development org—but with more storage for data and files than a standard Developer sandbox.
• Best for: Dev or QA scenarios that need larger sample datasets, more records for batch testing, or heavier integration fixtures without a Partial/Full sandbox.

Partial Copy Sandbox

• Metadata plus a subset of production data defined by a sandbox template (objects included, record sampling).
• Best for: QA and UAT when you need realistic relationships and picklist/record-type distributions without cloning all production rows.
• Watchouts: Template design matters; missing objects mean broken tests; sensitive data may still appear—masking policies apply.

Full Sandbox

• Metadata + full production data (at refresh time).
• Best for: Final UAT, training, performance testing, complex regression with production-scale volumes.
• Tradeoffs: Longer refresh cycles, higher cost/entitlement sensitivity, and data privacy obligations—Full sandboxes are still not “anonymous” by default.

Comparison table (exam mental model):

Refresh: Sandboxes age; a refresh re-copies from production per type rules and can wipe sandbox-only changes not captured in source control. That is a major reason teams keep metadata in Git rather than only in long-lived sandboxes.

Scratch Orgs and Salesforce DX

A scratch org is a short-lived, source-configurable Salesforce environment created on demand via Salesforce DX (CLI + project config). Unlike a sandbox, it is not primarily “a copy of our production.” It is “an empty-ish org shaped by a definition file (features, edition, settings) and then filled by pushing source and optional data plans.”

Defining characteristics:

• Ephemeral: Days of life (duration configurable within platform limits), then deleted.
• Repeatable: Any developer can spin the same shape from the repo.
• Source-driven: Metadata lives in the project; the org is a runtime projection.
• Parallelizable: Many scratch orgs for many branches/features without fighting over one shared sandbox.
• CI-friendly: Pipelines create a scratch org, deploy, test, and destroy.

project-scratch-def.json  →  sf org create scratch  →  push source  →  apex tests  →  delete org

Scratch org vs Developer sandbox:

Many mature teams use both: scratch orgs for feature branches and package development; sandboxes for long-running integration, UAT, and data-heavy tests.

Source-Driven Development

Source-driven development means:

1. Version control (Git) is the system of record for metadata.
2. Developers pull latest source, work in a personal scratch org or sandbox.
3. Changes are reviewed via pull requests.
4. CI deploys to integration environments and runs Apex tests.
5. Promotion artifacts (unlocked packages, metadata deployments, change sets in older models) move toward production.

Implications for PD1:

• Editing only in production or only in a shared sandbox without source control does not scale and risks overwrite on refresh.
• Change sets still appear in many orgs and exam histories as a promotion mechanism, but DX source deploy/packages are the modern baseline—know both concepts exist.
• Tests are part of the gate: deploy validation and CI should run the relevant Apex suite.

Promotion Path: Dev → Test → Staging → Prod

A common path to production:

Feature scratch org / Dev sandbox
        ↓  (merge + deploy)
Integration / QA test sandbox
        ↓  (UAT sign-off)
Staging (often Partial or Full)
        ↓  (release window)
Production

Rules of thumb:

• No direct hot-coding in production for normal features (emergencies still follow change control).
• Automations and Apex should be tested with data volumes that match risk (batch jobs need more than one Account).
• Profiles/permission sets, Connected Apps, and named credentials often need environment-specific values—plan config per org.
• Feature toggles / packaging versions help decouple deploy from immediate business activation.

Exam scenarios: “Where should a developer build a new trigger?” → non-production (scratch or Dev sandbox). “Where validate with production-like volumes?” → Full (or high-fidelity Partial). “How keep work when sandbox refreshes?” → source control, not only the sandbox.

Who Uses Which Environment

Shared sandboxes need hygiene: named data sets, agreements on who deploys when, and protection of integration user credentials.

Data vs Metadata Separation

This distinction is repeatedly testable:

Consequences:

• Refreshing a sandbox replaces data per type rules and can remove sandbox-only records—metadata not in source can vanish relative to team intent if it only lived in that sandbox.
• Partial Copy templates select which objects’ data come over; they are not a substitute for deploying a new custom field (that is metadata).
• Developers should build seed scripts or use DX data plan approaches so scratch orgs get the minimum records needed for tests—without copying production PII unnecessarily.
• Masking and privacy: even non-prod data can be regulated; Full sandboxes require governance.

Practical Strategy Patterns

Pattern A — DX package team

Scratch org per feature branch → unlocked package version → install in integration sandbox → UAT Full/Partial → prod install.

Pattern B — Metadata deploy team

Developer sandboxes → PR into main → CI deploys to QA sandbox → change review board → deploy to Full for UAT → prod deploy window.

Pattern C — Mixed reality

Scratch for pure code; Partial for regression against sampled prod data; Full only before major releases because refresh is expensive/slow.

Exam Checklist

1. Name four sandbox types and their data differences.
2. Define scratch org as disposable, DX/source-shaped, not a prod data clone by default.
3. Describe a promotion path that never starts in production.
4. Separate metadata vs data tooling and ownership.
5. Match persona → environment.
6. Explain why Git + deploy beats “only in the sandbox” when refreshes hit.

Environment strategy is how debugging and tooling from earlier sections stay safe: you break triggers in a scratch org, read logs there, promote tested source, and keep production boring—in the best possible way.