Developer Pro Sandbox
A Developer Pro Sandbox is a sandbox type that copies your production org's metadata but no production data, with 1 GB of data storage for testing payloads you create yourself.
Definition
A Developer Pro Sandbox is a sandbox type that copies your production org's metadata but no production data, with 1 GB of data storage for testing payloads you create yourself. It is the middle option between a standard Developer Sandbox (200 MB, metadata only) and a Partial Copy or Full Copy sandbox (with sampled or complete production data). The 5x storage upgrade over a standard Developer Sandbox is what makes Developer Pro the right choice for integration testing, code with large data dependencies, or training environments that need realistic data volumes.
Developer Pro Sandboxes refresh once per day, the same interval as standard Developer Sandboxes. They are included with Performance and Unlimited editions in limited quantities and can be purchased as add-ons. The org's metadata copy is complete (every object, field, Flow, Apex class, custom setting, and Lightning page comes through), so a fresh Developer Pro looks identical to production except for the empty data tables and a few system-only configurations.
How Developer Pro Sandboxes compare to the other sandbox types
The four sandbox types in one table
Salesforce offers four sandbox types: Developer (200 MB, metadata only, 1-day refresh), Developer Pro (1 GB, metadata only, 1-day refresh), Partial Copy (5 GB, sampled production data, 5-day refresh), and Full Copy (production-equal storage and data, 29-day refresh). Developer Pro sits in the storage-bigger-no-data lane, which is the right fit for tests that need volume but not the specific shape of production records.
What metadata only actually copies
A Developer Pro Sandbox copies every metadata component your org has: Apex classes and triggers, Flows, validation rules, page layouts, Lightning record pages, custom objects and fields, profiles and permission sets, custom settings, custom labels, email templates, and so on. It does not copy records (Accounts, Contacts, etc.) or files. Configuration that lives at the org level (Company Information, Fiscal Year) copies; configuration that depends on data (sharing rules referenced by specific roles, for instance) requires the data to exist before it functions correctly.
The 1 GB storage allocation and what it covers
Data Storage in a Developer Pro is 1 GB of structured records and roughly 0.5 GB of file storage, configurable by Salesforce Support. That holds approximately 500,000 standard records at 2 KB each. For most development and integration testing, that is more than enough. If you need a million records of test data, you are probably better served by a Partial Copy sandbox or by scripting bulk data creation in your Developer Pro.
Daily refresh and what refresh actually does
A refresh resets the sandbox to match the current production metadata and clears all data. The refresh runs in the background and typically completes in 30 minutes to a few hours depending on org size. After refresh, you log in to the sandbox as your usual user (now reset to the production profile and permission state) and find the metadata up to date but no data. Apex Schedulable jobs do not auto-restart; remember to re-schedule them after every refresh.
Comparing Developer Pro to a Scratch Org
A Salesforce DX scratch org is conceptually similar to a Developer Pro Sandbox: empty data, configurable metadata, fast to spin up. The differences are that scratch orgs are temporary (default 7-day lifespan, max 30 days), are defined by a project file in your repo, and do not copy from production (they start from a Dev Hub definition file). Developer Pro Sandboxes are persistent, mirror production exactly at refresh time, and are managed in Setup, not in source. Most teams use both: scratch orgs for feature development, Developer Pro Sandboxes for shared QA and integration testing.
Use cases that suit Developer Pro better than the alternatives
Developer Pro is the right pick when you need: realistic metadata copies of production (eliminating Developer''s 200 MB ceiling); enough room for bulk-data creation in tests (Apex test data, integration payloads, ETL exercises); a shared environment across two or three developers (scratch orgs are single-developer by default); a refresh cadence faster than Partial Copy''s 5-day window. If you also need production data, jump to Partial Copy or Full Copy.
Pricing and edition entitlements
Performance Edition includes one Full Copy and unlimited Developer Sandboxes plus a few Developer Pro by default. Unlimited Edition includes more Developer Pro entitlements. Enterprise Edition gets no Full Copy by default but typically gets a Developer Pro included. Additional Developer Pro Sandboxes can be purchased as add-ons. Check Setup, then Sandboxes, then Available Licenses for your specific org''s entitlement.
How to create and refresh a Developer Pro Sandbox
Creating a Developer Pro Sandbox takes about an hour for the initial spin-up. Refreshes are typically faster. The work is mostly in choosing the right sandbox type and naming it clearly.
- Open Sandboxes in Setup
Production org, then Setup, then Sandboxes. The page shows your current sandboxes and the available license counts for each type.
- Click New Sandbox
Click New Sandbox. Pick Developer Pro from the type dropdown. The form expands with naming and post-copy options.
- Name the sandbox
Sandbox name must be 10 characters or fewer (constraint), lowercase, no spaces. Use a meaningful name like devpro1 or intgtest. The sandbox URL will be your-domain--devpro1.sandbox.my.salesforce.com.
- Set a post-copy Apex class (optional)
If you have an Apex class that initializes seed data after a refresh, name it in the Post Copy Script field. The class implements SandboxPostCopy. This is the standard pattern for setting up users, sample records, or external test connections automatically.
- Confirm and start the creation
Click Create. Salesforce begins the metadata copy. You will get an email when it completes, typically within an hour for a typical-sized org.
- Log into the sandbox
Sandbox URL is https://test.salesforce.com or your domain''s sandbox subdomain. Username is your-prod-username.devpro1 (your production username with the sandbox name appended). Password is your production password at creation time.
Metadata only, 1 GB data storage, refresh daily. The middle ground.
Metadata only, 200 MB. Use for quick prototyping when storage is not a constraint.
Sampled production data based on a Sandbox Template. Use when your tests need realistic record shapes.
Production-equal data, refresh every 29 days. Use for performance testing, training, and pre-production validation.
- Sandbox names must be 10 characters or fewer. Salesforce will reject longer names with no helpful error message. Use abbreviations like devpro, intgtest, uat1.
- Apex Schedulable jobs do not survive a refresh. You have to re-schedule them after every refresh, either manually or through a post-copy Apex class.
- Storage in a Developer Pro is shared between data and files. A 1 GB allocation can fill up faster than you expect if your tests include image uploads or attachment downloads.
- Field Audit Trail data and Big Object records do not copy to Developer Pro Sandboxes. Any tests that depend on that data will need to repopulate it after the refresh.
Trust & references
Straight from the source - Salesforce's reference material on Developer Pro Sandbox.
- Sandbox Types and TemplatesSalesforce Help
- Sandbox Considerations and TipsSalesforce Help
- SandboxPostCopy InterfaceSalesforce Developers
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 Pro Sandbox copy?
Q2. How much test data storage does a Developer Pro Sandbox provide?
Q3. When would you choose Developer Pro over a regular Developer Sandbox?
Discussion
Loading discussion…