ExamFinch.com My Study

Study guide

15.3 Sandboxes, Scratch Orgs & Environment Strategy

Practice this exam

Salesforce Certified Platform Developer I Exam

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Blueprint Weights & Study Strategy

2 Platform Fundamentals

2.1 Multi-Tenant Architecture & Shared Resources 2.2 MVC Mapping on the Lightning Platform 2.3 Declarative vs Programmatic Decisions 2.4 Agentforce for Developers: Use Cases & Limitations

3 Data Modeling & Schema

3.1 Objects, Fields & Schema Design 3.2 Relationship Types & Implications 3.3 Schema Design Impact on Apex 3.4 Data Import & Export for Development

4 Platform Data Features

4.1 Formula Fields & Roll-Up Summaries 4.2 Core CRM Objects & Standard Schema 4.3 AppExchange Extensions & Platform Boundaries

5 Declarative Process Automation

5.1 Record-Triggered Flows & Declarative Automation 5.2 Approval Processes & Business Rules 5.3 When to Use Apex vs Declarative Tools

6 Apex Language Basics

6.1 Variables, Constants & Apex Data Types 6.2 Lists, Sets & Maps 6.3 Control Flow & Exception Handling 6.4 Classes, Interfaces & OOP Patterns

7 SOQL, SOSL & DML

7.1 SOQL Query Fundamentals 7.2 SOSL Search Fundamentals 7.3 DML Operations & Bulkification 7.4 Governor Limits & Transaction Boundaries

8 Apex Triggers & Order of Execution

8.1 Trigger Structure & Context Variables 8.2 Bulk Trigger Patterns & Best Practices 8.3 Save Order of Execution 8.4 Recursion, Cascading & Transaction Control

9 Asynchronous Apex

9.1 @future Methods 9.2 Queueable Apex 9.3 Batch Apex 9.4 Schedulable Apex & Job Orchestration

10 Security, Events & Schema Access

10.1 Sharing, FLS, CRUD & Injection Prevention 10.2 Platform Events Publish & Subscribe 10.3 Programmatic Schema Access (Describe)

11 Visualforce

11.1 Visualforce Pages & Markup 11.2 Standard, Custom Controllers & Extensions 11.3 Visualforce in Lightning Experience

12 Lightning Components

12.1 Lightning Component Framework Benefits 12.2 Aura Component Structure & Resources 12.3 Lightning Web Components Fundamentals 12.4 LWC Data Access: Wire, Imperative & Events

13 UI Composition & Apex Integration Patterns

13.1 Composing UI in Lightning Apps 13.2 UI Security, Performance & Accessibility Patterns 13.3 Apex Actions for Flow, LWC, and Agentforce

14 Apex Testing

14.1 Testing Framework & Coverage Requirements 14.2 Writing Unit Tests for Triggers & Classes 14.3 Test Data Strategies & Isolation 14.4 Executing Tests & Execute Anonymous Differences

15 Debugging & Developer Tools

15.1 Debug Logs & Monitoring 15.2 Developer Console, CLI, VS Code & Workbench 15.3 Sandboxes, Scratch Orgs & Environment Strategy

16 Deployment & Release

16.1 Change Sets & Metadata Deployment 16.2 Unlocked Packages, Metadata API & Salesforce DX 16.3 Release Readiness & Credential Maintenance

15.3 Sandboxes, Scratch Orgs & Environment Strategy

Key Takeaways Explain This Topic AI

Sandbox types trade data fidelity vs speed: Developer and Developer Pro for config/code, Partial Copy for sampled prod data, Full for complete prod-like data

Scratch orgs are short-lived, source-defined environments central to Salesforce DX and modern source-driven development

Promote along a path such as scratch/dev → integration/test → UAT/staging → production; never treat production as the first coding environment

Separate concerns: metadata (source, deploy) vs data (seed scripts, templates, masked subsets)—do not confuse record data with deployable metadata

Who uses what: developers favor scratch/Dev sandboxes; QA uses Partial/Full or dedicated test orgs; business UAT needs realistic data; prod is controlled release only

Last updated: August 2026

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.

  • Need Environment tendency
  • Fast iteration on Apex/LWC Scratch org or Developer sandbox
  • Integration tests with more storage Developer Pro or shared integration sandbox
  • Realistic data shapes without full prod copy Partial Copy
  • Performance/UAT with full volumes Full sandbox
  • Live users Production
  • 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):

  • Type Data Typical user
  • Developer Little Developer daily build
  • Developer Pro More capacity for data than Developer Dev/QA with larger fixtures
  • Partial Copy Sampled prod via template QA/UAT
  • Full Complete prod copy UAT, performance, training

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:

  • Topic Scratch org Developer sandbox
  • Origin Created from DX definition + source Copied from production metadata
  • Lifetime Short, disposable Longer-lived until refresh/delete
  • Data Empty unless you load it Sparse sample unless you load it
  • Best alignment Git branches, packages, CI Persistent individual/shared dev orgs
  • Prod shape Only as accurate as features/settings you enable Closer metadata baseline from prod copy

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:

Version control (Git) is the system of record for metadata.

Developers pull latest source, work in a personal scratch org or sandbox.

Changes are reviewed via pull requests.

CI deploys to integration environments and runs Apex tests.

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

  • Persona Typical environments
  • Apex/LWC developer Scratch org, Developer / Dev Pro sandbox
  • QA engineer Shared integration sandbox, Partial Copy
  • Business UAT tester Partial or Full sandbox with realistic data
  • Release manager Controls promotion into staging/prod; CLI/CI credentials
  • Admin configuring prod-only settings Controlled prod access with change tracking
  • Training lead Full sandbox (often) so training data mirrors prod

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:

Metadata Data

Apex classes, triggers, LWC, flows, objects, fields, page layouts, permission sets (as metadata) Account/Contact rows, files, chatter posts

Deployed via change sets, Metadata API, source deploy, packages Loaded via Data Loader, Bulk API, seed scripts, sandbox copy, manual entry

  • Belongs in Git Belongs in data plans , templates, or masked extracts
  • Defines structure and behavior Defines business records

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

Name four sandbox types and their data differences.

Define scratch org as disposable, DX/source-shaped, not a prod data clone by default.

Describe a promotion path that never starts in production.

Separate metadata vs data tooling and ownership.

Match persona → environment .

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.