Sandbox Types and Licensing Implications
Salesforce offers multiple sandbox types, each with different capabilities and licensing entitlements. Understanding these differences is key to planning a cost-effective sandbox strategy.
Developer Sandbox
Included- All production metadata, no data
- ~200 MB data / 200 MB file storage
- Refresh: daily
- Included even in lower editions
- Best for: individual development, unit testing
Developer Pro Sandbox
Higher Editions / Add-on- Metadata-only like Developer, larger storage
- ~1 GB data / 1 GB file storage
- Refresh: daily
- Included with higher editions or add-on purchase
- Best for: integration testing, larger dev tasks
Partial Copy Sandbox
Enterprise+ / Add-on- All metadata + subset of production data
- Define Sandbox Template for sample records
- Up to ~5 GB / 10,000 records per object
- Refresh: every 5 days
- Best for: QA with realistic data, integration testing
Full Copy Sandbox
Unlimited / Paid Add-on- Complete replica of production (all data + metadata)
- Full production data volume
- Refresh: every 29 days
- Only included with Unlimited Edition
- Best for: final UAT, performance testing, staging
Edition Differences
| Sandbox Type | Professional | Enterprise | Unlimited |
|---|---|---|---|
| Developer | Limited / Add-on | ✓ Included | ✓ Included (multiple) |
| Developer Pro | Not included | Add-on available | ✓ Included |
| Partial Copy | Not included | ✓ 1 Included | ✓ Included |
| Full Copy | Not included | Add-on (significant cost) | ✓ 1 Included |
Leveraging Developer Edition Orgs
In addition to sandboxes, Salesforce provides Developer Edition (DE) orgs — free, standalone orgs useful for initial development and experimentation.
Developer Edition Org (Free)
Free — No Licence Required- Many Enterprise Edition features (custom objects, Apex, etc.) with strict limits
- Very small data/storage allowance (a few MBs), typically 1–2 user accounts
- Not connected to production org — cannot be refreshed from production data
- Ideal for proof-of-concept, training, or building AppExchange packages
- Useful when sandbox capacity is constrained — developers can start building immediately
- Moving components to production requires manual deployment (Metadata API, packages)
Optimising Sandbox Licence Usage
📐 Right-Size Your Sandbox Allocation
Match sandbox types to their purpose. Avoid using a Full Copy for daily development — that's overkill in both data volume and cost. Use Developer/Dev Pro for development and unit testing, Partial Copy for data-intensive QA, and reserve Full Copy for final UAT or staging. This prevents "sandbox sprawl" and keeps costly environments limited to when they're truly needed.
🔒 Avoid Blanket Sandbox Access for All Users
Sandboxes should not be accessible to every production user by default. Limit active users in test environments to developers, admins, dedicated QA staff, and a subset of business user testers for UAT. Deactivating unnecessary accounts reduces risk, protects sensitive data, and lowers administrative overhead.
📊 Manage User Allocation Implications
While sandbox logins reuse production licences (no extra cost per user), each active user in a Full or Partial sandbox consumes data storage and generates system usage (API calls). If all 500 production users log into a Full sandbox, the load could require additional sandbox resources. Keep user counts lean to stay within comfortable limits.
🔄 Monitor and Recycle Sandbox Environments
Treat sandbox licences as capacity to be managed. Plan usage schedules for each sandbox (project or testing cycle), then refresh or repurpose for the next need. Don't leave sandboxes idle — an unused sandbox still counts against your licence quota. Salesforce will lock sandboxes that exceed your entitlement. Delete or archive completed project sandboxes to free up slots.
📚 Related Reading
QA, UAT, and Staging Environment Best Practices
Multi-Tiered SDLC Environments
Development
Individual sandboxes per developer or team for isolated build and unit test
Integration QA
Shared sandbox where code from different devs is integrated and tested with broader dataset
UAT
Final validation by power users and stakeholders with realistic data volumes and configurations
Staging / Pre-Prod
Final performance tests and dry-run deployments. Many customers combine this with the UAT sandbox
📅 Refresh Cadence and Data Management
Coordinate sandbox refreshes with testing cycles. Refresh the Full Copy just before UAT to ensure up-to-date test data. Update Partial Copy templates to include different data samples for upcoming tests. Factor in refresh limits (monthly for Full) when planning timelines. Implement data masking for sandboxes containing production data with sensitive information.
⚖️ Licence Efficiency in Testing
Use the smallest sandbox that meets each testing stage's needs. For a test requiring 1,000 records, a Partial Copy is more licence-efficient than refreshing the Full org. Reserve Full Copy for scenarios where lesser environments fall short — performance testing with full data volume or integrated UAT involving many objects.
👥 Collaboration and Training
Sandboxes are useful for training users on new features before go-live. A Partial or Full sandbox provides realistic data without affecting production. Limit training to specific users and timeframes to avoid occupying a full-data sandbox for extended periods. Plan whether a post-training refresh is needed before final UAT.
Real-World Examples of Strategic Sandbox Use
Global Retailer — Enterprise Edition (~200 Users)
Aggressive development roadmap. One Partial Copy sandbox included with Enterprise, plus one purchased Full sandbox add-on for comprehensive testing.
Strategy: Each developer works in individual Developer sandboxes (metadata-only, refreshed daily). Completed features deploy to a shared Integration QA sandbox (Developer Pro) where QA runs functional tests with a small manual test dataset. Partial Copy sandbox is refreshed with a template (key objects up to 5 GB) for integration testing of processes needing data context and super-user training. Full Copy sandbox is reserved for final UAT — refreshed before major releases, with only ~20 business users and IT staff given login access. After UAT sign-off, the Full sandbox serves as staging for dress-rehearsal deployments.
Mid-Market Tech Firm — Professional Edition
Very limited included sandboxes (one Developer sandbox by default). No Full or Partial sandboxes included with Professional Edition.
Strategy: The admin does initial build-out and unit testing in the provided Developer sandbox. Two developers each set up free Developer Edition orgs to experiment with integrations and Lightning components in parallel. As components mature, they're deployed into the lone Developer sandbox for integration testing with manually loaded sample data. For UAT, rather than purchasing a costly Full Copy, they conduct UAT in the production org during off-hours with test records — a controlled live pilot.
CIO Action Plan
Inventory Your Sandbox Entitlements
Document the number of sandboxes of each type your organisation has, your Salesforce edition, and associated contracts. Ensure you are aware of refresh limits and storage constraints for each sandbox.
Align Sandbox Types with SDLC Stages
Define a development lifecycle and assign sandbox types accordingly — Developer for development, Partial for QA, Full for UAT. Use the smallest sandbox necessary at each stage to conserve resources.
Optimise Licence Usage
Avoid over-provisioning sandboxes or users. Only purchase additional sandboxes (e.g., Full copies) if testing requirements clearly demand it. Utilise free Developer Edition orgs or share sandboxes among team members when budget is tight.
Control Sandbox Access
Implement governance on who can access each sandbox. Activate accounts only for testers/developers who need it. This protects data and reduces the chance of configuration drift or accidental changes by unauthorised users.
Plan Refresh and Data Strategy
Plan sandbox refresh schedules in tandem with release cycles. Before major tests, refresh relevant sandboxes to mirror production. Use sandbox templates (for Partial Copy) and consider data masking tools for sensitive information.
Monitor and Review Costs
Treat sandbox licences as part of your Salesforce cost structure. Monitor usage — are all sandboxes being used effectively? Can any be eliminated or consolidated? Ahead of renewals, review if your sandbox mix is still appropriate.
Leverage Independent Expertise
Stay informed on Salesforce licensing changes and seek independent advice before negotiating contracts or making edition upgrades for sandbox needs. An unbiased review of licence and sandbox usage can identify opportunities to reduce cost or improve compliance.
By following this action plan, CIOs can ensure their Salesforce environments support development and testing needs without incurring unnecessary licensing costs or management burdens. The result is a more efficient, compliant, and agile Salesforce operation.
Optimising Your Salesforce Sandbox & Licensing Strategy?
Salesforce contracts are complex — sandbox entitlements, edition upgrades, user licence mix, and renewal terms all interact in ways that can cost or save your organisation significant money. Our Salesforce licensing specialists help enterprises right-size sandbox allocations, negotiate favourable contract terms for development environments, and ensure licence compliance across production and non-production orgs. Get an independent, vendor-neutral review before your next Salesforce renewal.