Salesforce Sandbox Creation: Full Setup Guide

Before any code, configuration, or deployment goes to production, it goes to a sandbox. Understanding how to create, configure, and manage sandboxes correctly is one of the foundational skills in Salesforce development. This session covers every sandbox type, the creation process, and the decisions that determine which sandbox you need.

The four sandbox types

Salesforce provides four sandbox environments, each suited to different use cases and each with different storage limits, data copy behaviour, and refresh cycles.

Developer sandbox gets 200MB of storage and copies metadata only — no records. It refreshes every day, which makes it the right choice for individual developer workstreams where frequent resets are useful. Every Salesforce org includes a Developer sandbox allocation.

Developer Pro sandbox expands storage to 1GB while keeping the same metadata-only copy behaviour and daily refresh cycle. Developer Pro is useful when the 200MB Developer limit becomes a constraint — large numbers of custom objects, extensive metadata, or Apex code.

Partial Copy sandbox provides 5GB and copies both metadata and a subset of data defined by a sandbox template. Refresh cycle is every 5 days. Partial Copy is the right environment for feature testing that requires data — QA, UAT, and integration testing where realistic records matter but a full production data copy is not needed.

Full Copy sandbox matches production storage exactly and copies all metadata and all data. Refresh cycle is every 29 days. Full Copy is the right environment for performance testing, load testing, and final release validation where exact production parity is required. Full Copy creation takes significantly longer — hours to days depending on org size.

Creating a sandbox: step by step

In Salesforce Setup, navigate to Environments → Sandboxes → New Sandbox.

Enter a sandbox name. This is critical: the name must be 10 characters or fewer, and it becomes the suffix appended to every username in that sandbox. If your production username is [email protected] and you name the sandbox dev1, your sandbox login is [email protected]. Choose names that are easy to type and meaningful — you will type them frequently.

Select the sandbox type. Your org license determines which types are available. If you select Partial Copy, you can also choose a sandbox template that defines which objects and records to include.

Optionally, specify an Apex class to run after the sandbox is created. This is useful for seeding test data, deactivating scheduled jobs, or setting configuration values that differ between production and sandbox.

Click Create. Developer sandboxes complete in minutes. Full Copy sandboxes can take 24–48 hours. Salesforce will email the sandbox creator when the environment is ready.

Sandbox templates

Sandbox templates control which records are copied to Partial Copy sandboxes. Without a template, Salesforce copies a random sample — typically 10,000 records — from each object. With a template, you specify exactly which objects to include and define criteria for which records to pull.

Configure templates in Setup → Sandbox Templates → New. Add the objects you want included and set any filter criteria. A well-designed template gives QA and UAT testers a consistent, predictable dataset without exposing sensitive production records.

Full Copy sandboxes do not use templates — they copy everything.

Email deliverability in sandboxes

Salesforce automatically appends .invalid to all email addresses copied into sandboxes. This prevents accidental emails to real customers from test environments. Any email-sending workflow in a sandbox will not deliver unless you explicitly configure email deliverability.

In sandbox Setup, go to Email → Deliverability. The default setting is "System email only," which allows Salesforce system notifications but blocks outbound emails from workflows and Apex. Change to "All email" only when you need to test an email delivery flow end-to-end — and restore it when testing is complete.

After sandbox creation

After creation, log in with your sandbox-specific credentials (username.sandboxname). The first tasks are typically: verify the environment is correct, check that your Apex post-copy class ran if specified, and confirm that environment-specific custom settings and metadata credentials point to sandbox values rather than production endpoints.

For active development, set up your Salesforce CLI connection immediately: sf org login web --alias dev1 --instance-url https://dev1.sandbox.my.salesforce.com. Having the alias configured means all subsequent CLI commands can target the sandbox by name without re-authenticating.