Developer Sandbox
A Developer Sandbox is the smallest Salesforce sandbox type: a copy of your production org's metadata with 200 MB of data storage for testing payloads you create yourself.
Definition
A Developer Sandbox is the smallest Salesforce sandbox type: a copy of your production org's metadata with 200 MB of data storage for testing payloads you create yourself. It is the most commonly provisioned sandbox because every Enterprise, Performance, and Unlimited Edition org gets multiple Developer Sandboxes included, and the 1-day refresh interval makes them practical for daily development work. Developer Sandboxes are the right starting point for any individual developer or admin who needs a safe environment to build and test changes.
The sandbox copies every metadata component (Apex, Flows, custom fields, profiles, validation rules, page layouts, custom settings) but no records, files, or content. The 200 MB allocation holds roughly 100,000 standard records at 2 KB each, which is plenty for most unit tests and feature work. When you need more storage or production data shapes, you move up to Developer Pro, Partial Copy, or Full Copy. For 80 percent of dev tasks, Developer Sandbox is the right fit.
How Developer Sandboxes fit Salesforce's sandbox lineup
What 200 MB of data storage actually holds
Salesforce bills sandbox data storage at 2 KB per standard record, the same rate as production. 200 MB allocates space for approximately 100,000 records: enough for a few hundred Accounts, several thousand Contacts, tens of thousands of Tasks or EmailMessages used in tests, plus the supporting Apex test data. Add a few hundred attachments and you start bumping against the limit. For 90 percent of feature development, 200 MB is enough; for integration testing with real-shape data, move to Developer Pro or Partial Copy.
Metadata copies and what comes through
Every metadata component in production copies to a new or refreshed Developer Sandbox: Apex classes and triggers, Flows, validation rules, custom objects and fields, profiles and permission sets, page layouts and Lightning Record Pages, custom settings, custom labels, email templates, dashboards (definitions, not the data), reports, and so on. Standard objects and their fields come through too. Configuration that lives at the org level (Fiscal Year, Company Info, default record types) copies. What does not copy: actual record data, files, content, and a few system-only configurations.
The 1-day refresh interval
A Developer Sandbox can be refreshed once per day. The refresh resets the sandbox to current production metadata, clears all data, and takes 30 minutes to a few hours to complete. The cadence is fast enough that most teams keep Developer Sandboxes in sync with production weekly or bi-weekly without painful coordination. Compare this with Partial Copy''s 5-day window and Full Copy''s 29-day window: Developer is the most refresh-friendly sandbox type.
Edition entitlements and how many you get
Enterprise Edition includes 25 Developer Sandboxes by default. Performance and Unlimited Edition include 100 or more. Professional Edition typically does not include Developer Sandboxes (purchase as add-on). Each developer on a team usually gets their own; large orgs have dozens spun up. Setup, then Sandboxes, then Available Licenses, shows your current entitlement and how many slots are free.
Developer Sandbox versus Scratch Org
A Salesforce DX scratch org is conceptually similar to a Developer Sandbox: empty data, configurable metadata, fast to spin up. The differences are that scratch orgs are temporary (default 7-day lifespan), are defined by a project''s source files, and start from a Dev Hub definition rather than copying production. Developer Sandboxes are persistent, mirror production exactly at refresh time, and are managed in Setup. Use scratch orgs for daily feature development; use Developer Sandboxes for shared QA and integration patterns.
Naming, URL pattern, and access
Sandbox names must be 10 characters or fewer (a hard constraint), lowercase, no spaces. The sandbox URL is your-domain--sandboxname.sandbox.my.salesforce.com. Username for sandbox login is your production username with the sandbox name appended: jane.doe@example.com becomes jane.doe@example.com.sandboxname. Password is the production password at creation time.
Common pitfalls when relying on Developer Sandboxes
Three pitfalls trip up teams new to Developer Sandboxes. First, the 200 MB ceiling: tests that load realistic data volumes fail mysteriously when storage runs out. Second, the metadata-only copy: features that depend on existing data (sharing rules, role hierarchy referenced by specific users, dynamic reports) need seed data after every refresh. Third, the absence of file storage allocation for attachments: Files and ContentVersion records can exhaust file storage even when data storage looks healthy.
How to provision a Developer Sandbox
Provisioning a Developer Sandbox is the simplest sandbox creation flow. Choose the name, optionally set a post-copy script, and Salesforce builds the environment in under an hour.
- Open Sandboxes in production Setup
Setup, then Sandboxes. The page lists existing sandboxes and shows your available license counts.
- Click New Sandbox and pick Developer
Click New Sandbox. Pick Developer from the type dropdown. The form expands with naming options.
- Name the sandbox
Sandbox name: 10 characters or fewer, lowercase, no spaces. devsbx1, devjane, qaint are typical names. The name becomes part of the URL and the username suffix; pick something meaningful.
- Optional: set a post-copy Apex class
In the Post Copy Script field, name an Apex class that implements SandboxPostCopy. The class runs automatically after creation and refresh. Use it to seed test data, configure connected apps, or set up users.
- Confirm and create
Click Create. Salesforce begins the metadata copy. Expect 30 minutes to a few hours; you receive an email when complete.
- Log in
Use the URL https://test.salesforce.com or your domain''s sandbox subdomain. Username is your-prod-username.sandboxname. Password is your production password as of creation time.
Metadata only, daily refresh. The most common starting point.
Larger sibling. Use when 200 MB is not enough but you do not need production data.
Bigger jump for tests that need realistic record shapes.
Production-equal data, 29-day refresh. Used for pre-production and training.
- 200 MB fills up faster than you expect once you start loading test data. Bulk inserts of 50,000 EmailMessages can fill the allocation by themselves.
- Sandbox name is permanent. You cannot rename a sandbox; deleting and recreating is the workaround.
- Apex Schedulable jobs do not survive a refresh. Re-schedule them after every refresh, manually or via a post-copy Apex class.
- Sandboxes share Salesforce''s storage limits with production. Heavy attachment uploads in a sandbox can affect what is available across the broader environment in unusual edge cases.
Trust & references
Straight from the source - Salesforce's reference material on Developer Sandbox.
- Sandbox Types and TemplatesSalesforce Help
- Sandbox Considerations and TipsSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What does a Developer Sandbox copy from production?
Q2. How often can you refresh a Developer Sandbox?
Q3. What's the typical use case for Developer Sandboxes?
Discussion
Loading discussion…