Sandbox Types and Development Environments

Sandbox Types and Development Environments – Salesforce Platform Developer 1 Exam Guide

Why Sandbox Types and Development Environments Matter

Understanding sandbox types and development environments is a critical competency for any Salesforce Platform Developer. In real-world projects, choosing the wrong sandbox can lead to wasted time, incomplete testing, and even production issues. On the Salesforce Platform Developer 1 exam, questions in the Testing, Debugging, and Deployment section frequently test your knowledge of which sandbox to use for a given scenario, what data and metadata each sandbox includes, and how refresh intervals work. Mastering this topic ensures you can both pass the exam and apply best practices in your daily development work.

What Are Sandboxes?

A sandbox is a copy of your Salesforce production organization used for development, testing, training, or staging purposes. Sandboxes are isolated environments, meaning changes made in a sandbox do not affect your production org until you explicitly deploy them. Salesforce provides four types of sandboxes, each designed for different use cases.

The Four Sandbox Types

1. Developer Sandbox
- Purpose: Development and unit testing
- Metadata: Full copy of production metadata (configuration, Apex classes, triggers, custom objects, workflows, etc.)
- Data: No production data is copied. The sandbox starts empty in terms of records.
- Storage: 200 MB of data storage and 200 MB of file storage
- Refresh Interval: Once per day (1 day)
- Key Use Case: Individual developers writing and testing code in isolation. Each developer on a team can have their own Developer Sandbox.

2. Developer Pro Sandbox
- Purpose: Development and testing that requires more data or larger datasets
- Metadata: Full copy of production metadata
- Data: No production data is copied. The sandbox starts empty in terms of records.
- Storage: 1 GB of data storage and 1 GB of file storage
- Refresh Interval: Once per day (1 day)
- Key Use Case: Developers or teams needing more storage than a standard Developer Sandbox provides, or for projects that involve loading larger sample datasets for testing. Also useful for quality assurance (QA) processes that do not require production data.

3. Partial Copy Sandbox
- Purpose: Testing and QA with a subset of production data
- Metadata: Full copy of production metadata
- Data: Includes a sample (subset) of production data, defined by a sandbox template. A sandbox template lets you select which objects' records to copy.
- Storage: 5 GB of data storage and 5 GB of file storage
- Refresh Interval: 5 days
- Key Use Case: User acceptance testing (UAT), integration testing, and QA activities where realistic data is needed but a full production data copy is unnecessary or impractical.

4. Full Sandbox
- Purpose: Staging, performance testing, load testing, and complete replica testing
- Metadata: Full copy of production metadata
- Data: Full copy of all production data (records, attachments, etc.)
- Storage: Same storage as your production org
- Refresh Interval: 29 days
- Key Use Case: Final staging before deployment, performance testing, load testing, training environments that need the complete dataset. Due to its long refresh cycle and high resource cost, Full Sandboxes should not be used for day-to-day development.

Quick Comparison Table

Developer → Metadata only, 200 MB, 1-day refresh
Developer Pro → Metadata only, 1 GB, 1-day refresh
Partial Copy → Metadata + sampled data (template), 5 GB, 5-day refresh
Full → Metadata + all data, same as production, 29-day refresh

How Sandboxes Work

Creation and Refresh: Sandboxes are created from the production org under Setup → Sandboxes. When you create or refresh a sandbox, Salesforce copies metadata (and data, depending on type) from production. During a refresh, the existing sandbox is replaced by a new copy. Any changes you made in the old sandbox that were not deployed to production are lost upon refresh.

Sandbox Templates: Sandbox templates are used exclusively with Partial Copy and Full sandboxes. They allow you to define which objects and how many records to include. For Partial Copy sandboxes, templates are required to determine the data subset. For Full sandboxes, templates are optional (if not specified, all data is copied).

Login and Access: Sandbox environments have their own login URL (typically https://test.salesforce.com). Usernames in a sandbox are appended with the sandbox name (e.g., user@company.com.sandboxname). Passwords and user permissions are copied from production at the time of creation or refresh.

Deployment: Once development and testing are complete in a sandbox, changes are deployed to production using tools such as Change Sets, Salesforce CLI (sfdx), Metadata API, or third-party tools like Copado or Gearset.

Other Development Environments

While sandboxes are the primary development environments, you should also be familiar with:

Developer Edition Org: A free, standalone Salesforce org (not connected to any production org). It comes with limited storage and is commonly used for learning, experimentation, and building AppExchange packages. It is not a sandbox.

Scratch Orgs: Temporary, configurable Salesforce orgs created using Salesforce DX (SFDX). Scratch orgs are source-driven and can be configured with specific features and settings using a scratch org definition file. They typically last 1–30 days (default is 7). Scratch orgs are ideal for source-driven development, continuous integration (CI), and automated testing. They are part of the modern Salesforce development lifecycle.

Trailhead Playground: A hands-on learning environment similar to a Developer Edition org, provisioned through Trailhead. Not used in professional development but worth knowing.

How to Choose the Right Sandbox – Scenario-Based Thinking

This is the key skill tested on the exam. Here is the decision framework:

- A developer needs an isolated environment to write Apex code: → Developer Sandbox
- A team needs to test with a representative sample of production data: → Partial Copy Sandbox
- The team is performing load/performance testing before a major release: → Full Sandbox
- A developer needs more storage than a Developer Sandbox but does not need production data: → Developer Pro Sandbox
- A developer is using source-driven development with CI/CD pipelines: → Scratch Org
- A developer wants to build and test an AppExchange package independently: → Developer Edition Org

Exam Tips: Answering Questions on Sandbox Types and Development Environments

Tip 1: Memorize the Four Sandbox Types and Their Key Differences
Know the metadata vs. data inclusion, storage limits, and refresh intervals. The most commonly tested differentiator is whether production data is included. Remember: Developer and Developer Pro do not include data. Partial Copy includes a sampled subset. Full includes all data.

Tip 2: Focus on Refresh Intervals
Questions may present a scenario where the answer hinges on how often a sandbox can be refreshed. Developer and Developer Pro can be refreshed daily. Partial Copy every 5 days. Full every 29 days.

Tip 3: Understand Sandbox Templates
Remember that sandbox templates define which objects' data to include. They are used with Partial Copy (required) and Full (optional) sandboxes. If a question mentions selecting specific objects to copy, the answer likely involves a Partial Copy Sandbox with a template.

Tip 4: Do Not Confuse Developer Edition Orgs with Developer Sandboxes
A Developer Edition org is a free, standalone environment. A Developer Sandbox is linked to a production org and copies its metadata. Exam questions may try to trick you with this distinction.

Tip 5: Know When to Use Scratch Orgs
If the question references Salesforce DX, source-driven development, or continuous integration, the answer is likely a scratch org, not a sandbox.

Tip 6: Match the Scenario to the Sandbox
The exam loves scenario-based questions. Always ask yourself: Does this scenario require production data? How much storage is needed? Is this for development, testing, staging, or training? Use the decision framework above to match the scenario to the correct sandbox type.

Tip 7: Remember That Full Sandboxes Are Expensive
Questions may describe a scenario and include Full Sandbox as an option. If the scenario is simple development or testing without the need for all production data, Full Sandbox is likely the wrong answer. Salesforce best practice is to use the smallest appropriate sandbox type.

Tip 8: Deployment Is a Separate Step
Changes in a sandbox are never automatically reflected in production. You must deploy them. Understand that Change Sets, Metadata API, and Salesforce CLI are the primary tools for moving changes from sandbox to production.

Tip 9: Watch for Tricky Wording
Pay attention to phrases like subset of data (Partial Copy), all data (Full), metadata only (Developer or Developer Pro), and source-driven development (Scratch Org). These keywords are strong indicators of the correct answer.

Tip 10: Practice with Real Scenarios
Review Trailhead modules on Sandbox management and Salesforce DX. Create sandboxes in a Developer Edition org or Trailhead Playground to see firsthand how they work. Hands-on experience reinforces conceptual understanding and helps you answer scenario questions with confidence.

Summary

Sandboxes are essential to the Salesforce development lifecycle. The four types — Developer, Developer Pro, Partial Copy, and Full — serve different purposes based on their data inclusion, storage capacity, and refresh intervals. Combined with scratch orgs and Developer Edition orgs, they form a comprehensive set of environments for building, testing, and deploying Salesforce applications. For the Platform Developer 1 exam, focus on understanding which sandbox to use in which scenario, memorize key facts about each type, and practice distinguishing between similar-sounding options. This knowledge will serve you well on exam day and throughout your Salesforce development career.