Sandbox
A Sandbox is a copy of your Salesforce production environment used for development, testing, and training.
Definition
A Sandbox is a copy of your Salesforce production environment used for development, testing, and training. Sandboxes come in four types: Developer, Developer Pro, Partial Copy, and Full. They allow teams to build and test changes in isolation before deploying to production, protecting live data and users from unfinished or buggy configurations.
In plain English
“Here's a simple way to think about it: a Sandbox is a copy of your production environment for development, testing, and training. Four types - Developer, Developer Pro, Partial Copy, Full - trading data fidelity for refresh cost. The safety net under every Salesforce change.”
Worked example
Before deploying a major update to their lead scoring process, the team at Apex Dynamics refreshes a Full Sandbox to get a recent copy of production data and metadata. The developer builds and tests the new Apex trigger in the sandbox, the QA team validates it with realistic data, and only after all tests pass do they deploy to production via a change set.
Why Sandboxes are the safety net under every Salesforce change
Production is the org users actually depend on. Sandboxes are everything else - the Developer sandbox where one admin builds in isolation, the Partial Copy where a team integration-tests with a slice of real data, the Full sandbox where a release candidate gets dress-rehearsed against the complete org. Each tier trades data fidelity, refresh frequency, and license cost for a different level of confidence in what you're testing.
The reason every serious Salesforce program has a sandbox strategy is that production is unforgiving. A flow that works in a Developer sandbox may fail at scale in a Full sandbox; a bulk update that worked in test data may misbehave on a million real records. Build a tiered sandbox strategy that matches your release process - Developer for individual work, Partial Copy for integration testing, Full for pre-production verification - and keep them refreshed on a cadence that prevents drift from production.
How to set up Sandbox
Sandboxes are full-or-partial copies of your Production org used for development, testing, and training. Creating one is fast in admin time but slow in clock time — Full Sandboxes can take hours to provision. Pick the type carefully: refresh limits and costs differ wildly.
- Open Setup → Sandboxes (in Production)
Sandboxes are managed from the Production org, not from inside another sandbox. Setup → Quick Find: Sandboxes → Sandboxes.
- Click New Sandbox
Top-right. Click count is rate-limited per Sandbox type.
- Pick the Sandbox Type
Developer (no data, smallest), Developer Pro (no data, larger limits), Partial Copy (sample data, sandbox templates), Full Copy (production-like data, slowest to refresh).
- Name the Sandbox
Username convention: every user becomes user@yourorg.<sandboxname>. Pick a name that's easy to remember in URLs and not too long.
- For Partial / Full: pick a Sandbox Template (optional)
Templates control which objects' data is copied. Without one, all objects come along.
- Set Activation Email
Email sent to the user (you) when provisioning finishes.
- Click Create → wait
Developer takes minutes. Full takes hours-to-a-day. The activation email is the signal it's ready.
Developer, Developer Pro, Partial Copy, Full Copy. Each has different storage, refresh interval, and licensing costs.
Defines which objects' data is copied. Lets you scope the refresh.
Developer: 1 day. Developer Pro: 1 day. Partial: 5 days. Full: 29 days. You can't refresh more often than this.
Optional Apex class that runs after the sandbox is created/refreshed. Handy for dummy-data setup.
- Refresh intervals are floors, not ceilings. A Full Sandbox can only be refreshed every 29 days — plan release work around the cadence.
- Sandbox usernames are <prod-username>.<sandboxname>. Users land in the sandbox with the same password as Production initially — until first sandbox-only login, the password sync is one-way.
- Outbound emails from sandboxes are off by default. To send real email from a sandbox, change Setup → Email Deliverability → Access Level to All Email — but this is dangerous, do it only for short test windows.
How organizations use Sandbox
Runs a tiered sandbox strategy: each developer holds a personal Developer sandbox, the team integration-tests in a shared Partial Copy refreshed monthly, and a Full sandbox is refreshed two weeks before each major release for UAT. The per-tier discipline means a release candidate has been exercised against production-grade data volume before it ships.
Uses a Sandbox Template on every Partial Copy refresh so the same 30 GB slice of relevant data (recent transactions, the test customer pool, the regulatory-reporting dataset) lands consistently. Without the template, prior refreshes had pulled random subsets and missed the edge cases the testing team was looking for.
Treats their Full Sandbox as a "release rehearsal" environment - every change set proposed for production is first deployed to Full, run against a copy of yesterday's transactions, and only promoted to production after the QA team signs off. The discipline added a day to release cycles and eliminated emergency rollbacks for two consecutive years.
Trust & references
Straight from the source - Salesforce's reference material on Sandbox.
- SandboxesSalesforce Help
Hands-on resources to go deeper on Sandbox.
Test your knowledge
Q1. What is the primary benefit of Sandbox for Salesforce administrators?
Q2. Can a Salesforce admin configure Sandbox without writing code?
Q3. Why is understanding Sandbox important for Salesforce admins?
Discussion
Loading discussion…