10.2 Sandbox Types, Capacity & Refresh Cycles

10.2 Sandbox Types, Capacity & Refresh Cycles

A Sandbox is an isolated copy of a Salesforce production organization used for development, testing, training, and staging without jeopardizing the data integrity or operational stability of the live business environment. Sandbox metadata and data are isolated from the production org, but copied endpoints and credentials can still reach live external systems. Disable or repoint integrations before testing.

Salesforce provides four distinct sandbox tiers, each engineered with specific storage capacities, refresh frequencies, and data copying behaviors. Selecting the appropriate sandbox type for each stage of the application lifecycle is a core competency evaluated on the Platform App Builder certification exam.

---

The Four Salesforce Sandbox Types

[Metadata Only] ────────────────────────────────────────► [Metadata + Sample Data] ──► [Full Replica]
Developer (200MB / 1-Day)   Developer Pro (1GB / 1-Day)   Partial Copy (5GB / 5-Day)   Full (1:1 / 29-Day)

1. Developer Sandbox

The Developer Sandbox is the foundational building block for individual development and configuration:

• Data Storage Limit: 200 MB
• File Storage Limit: 200 MB
• What is Copied: Metadata only. No standard or custom record data is copied from the production organization.
• Refresh Interval: Once every 1 day (24 hours).
• Primary Purpose: Individual declarative development, building and testing flows, prototyping schema modifications, writing Apex triggers, and executing unit tests in total isolation.
• Key Characteristics: Lightweight, quick to provision and refresh. Because it contains zero production records, developers must manually create synthetic test records or import mock data via tools like Data Import Wizard or Data Loader.

2. Developer Pro Sandbox

The Developer Pro Sandbox serves as a higher-capacity development and integration environment:

• Data Storage Limit: 1 GB
• File Storage Limit: 1 GB
• What is Copied: Metadata only. Like the Developer Sandbox, no standard or custom record data is copied from production.
• Refresh Interval: Once every 1 day (24 hours).
• Primary Purpose: Quality assurance (QA), integration testing, developer aggregation, user training development, and tasks requiring larger mock datasets.
• Key Characteristics: Provides five times the storage capacity of a Developer Sandbox while retaining the agility of a 1-day refresh interval. It is ideal for consolidating work from multiple Developer Sandboxes to test interactions between separate features before moving upstream.

3. Partial Copy Sandbox

The Partial Copy Sandbox introduces real-world sample business data into the testing cycle:

• Data Storage Limit: 5 GB
• File Storage Limit: Same as production
• What is Copied: Metadata copy PLUS a sample of production record data defined by a Sandbox Template.
• Refresh Interval: Once every 5 days.
• Primary Purpose: User Acceptance Testing (UAT), integration testing with realistic relational data, business workflow verification, and quality assurance testing.
• Key Characteristics: For each object specified in the sandbox template, Salesforce copies up to 10,000 records (subject to the 5 GB overall data storage cap). Crucially, Salesforce maintains relational integrity across related objects (e.g., copying selected Accounts alongside their related Contacts, Cases, and Opportunities).

4. Full Sandbox

The Full Sandbox is an exact 1:1 functional and architectural replica of the production environment:

• Data Storage Limit: Identical to the production organization (e.g., if production has 120 GB of data storage, the Full Sandbox receives 120 GB).
• File Storage Limit: Identical to the production organization.
• What is Copied: Metadata and production record data, subject to selected template and copy options. Chatter and field history are configurable, so verify them explicitly.
• Refresh Interval: Once every 29 days.
• Primary Purpose: Final pre-production staging, release rehearsal, performance and load testing, end-to-end regression testing, and comprehensive User Acceptance Testing.
• Key Characteristics: Because it duplicates the entire production database, creating or refreshing a Full Sandbox can take several hours to multiple days depending on data volume. The platform imposes a strict 29-day waiting period between refreshes.

---

Sandbox Templates: Architecture & Capabilities

A Sandbox Template is a declarative configuration tool that dictates which standard and custom object records are copied into a sandbox during creation or refresh:

1. Object Selection: Administrators select specific objects in Setup > Sandbox Templates. Checking an object marks it for data sampling.
2. Relational Integrity Preservation: When parent objects are selected, Salesforce automatically includes related child records based on master-detail and lookup relationships (up to the 10,000 record sampling limit per object for Partial Copy).
3. Supported Sandbox Types: Sandbox Templates can only be utilized with Partial Copy Sandboxes (where a template is strictly mandatory) and Full Sandboxes (where it is optional). Developer and Developer Pro sandboxes do not support sandbox templates because they copy zero record data.

---

Sandbox Creation, Refresh & Activation Lifecycle

Refreshing a sandbox creates an exact point-in-time snapshot of the source production organization. Understanding the three distinct operational phases of a refresh is critical for exam success:

[1. Request Refresh] ──► [2. Platform Processing / Copying] ──► [3. Manual or Auto-Activation]

Phase 1: Request Refresh

An administrator initiates a refresh from the Sandboxes menu in Setup. If the sandbox is a Partial Copy or Full sandbox with a template, the template is selected. The request enters a processing queue.

Phase 2: Processing & Snapshot Creation

Salesforce takes a metadata snapshot (and data snapshot if applicable) of production. During this time, the sandbox status displays as Processing. The existing sandbox remains fully online and accessible to users while the new snapshot is compiled in the background.

Phase 3: Activation

Once processing completes, the sandbox status changes to Ready for Activation:

• Manual vs. Automatic Activation: Administrators can configure the sandbox to activate automatically upon completion or require a manual "Activate" button click.
• Destruction of the Previous Instance: When a refreshed sandbox is activated, the existing sandbox instance is permanently deleted. All uncommitted metadata, local configuration changes, local test users, and un-backed-up data in that sandbox are irrevocably destroyed.
• Downtime Window: During activation, the sandbox is taken offline and replaced with the newly provisioned instance.

---

Automated Sandbox Modifications: Email & User Safeguards

To prevent test environments from inadvertently interacting with live external systems, customers, or partners, Salesforce automatically applies several platform safeguards whenever a sandbox is created or refreshed:

1. User Email Address Masking (.invalid)

All standard user email addresses in the newly refreshed sandbox are modified by appending .invalid to the end of the address: $\text{john.doe@company.com} \longrightarrow \text{john.doe@company.com.invalid}$ This protects user email addresses; it does not mask Contact/Lead addresses, external endpoints, or every possible recipient. Review deliverability and integrations before testing. If a specific user needs to test outbound email functionality, an administrator must manually edit that user's record inside the sandbox and remove the .invalid suffix (which triggers standard email confirmation verification).

2. Email Deliverability Settings

By default, the global Email Deliverability setting in newly created or refreshed sandboxes is automatically set to System email only (allowing only platform notifications like password resets). Outbound business emails generated by flows, workflow rules, or Apex triggers are completely blocked until an administrator explicitly changes deliverability to All email in Setup.

3. Username Suffixing

To maintain globally unique Salesforce usernames across the multitenant cloud, all usernames in a sandbox are appended with the sandbox name: $\text{admin@company.com} \longrightarrow \text{admin@company.com.qa}$

---

Comprehensive Comparison Table: Salesforce Sandbox Tiers

---

Exam Traps and Best Practices

• Trap: Believing Developer Pro copies sample production data. Developer Pro sandboxes do NOT copy any production records. They copy metadata only, just like standard Developer Sandboxes. The sole difference is storage capacity (1 GB vs. 200 MB).
• Trap: Refreshing a Full Sandbox for Minor Iterations. Because a Full Sandbox has a strict 29-day refresh interval, teams must never refresh it lightly. If a Full Sandbox is refreshed right before a critical staging rehearsal, the team will be locked out from refreshing it for nearly an entire month.
• Trap: Creating a Partial Copy Sandbox without a Template. You cannot create or refresh a Partial Copy Sandbox without selecting an active Sandbox Template. If no template exists in Setup, the Partial Copy option cannot be submitted.

Storage Upgrades and Refresh Timing

The standard Developer data allowance is 200 MB and Developer Pro is 1 GB. Current sandbox documentation also offers eligible storage upgrades to 400 MB and 2 GB respectively; file allowances remain 200 MB and 1 GB. Use the stated or provisioned allowance in a scenario. A refresh interval is a minimum eligibility interval, not a promise that copying completes at that time. Preserve sandbox-only work before activation. A Full sandbox may use a template or omit history/Chatter, so verify production-volume fidelity before a performance rehearsal.

Official Source Check

Checked October 19, 2026: Sandbox storage and refresh allocations.