Salesforce sandboxes are critical for safe development and testing, but they also carry licensing implications that CIOs must manage strategically. This playbook covers sandbox types, licensing considerations, and best practices for environment strategies, helping CIOs balance test coverage and cost efficiency.
This playbook is part of our Salesforce Licensing Knowledge Hub. See also: Salesforce Licence Types Guide | Contract Terms to Negotiate | Licence Optimisation Playbook.
Salesforce offers multiple sandbox types, each with different capabilities and licensing entitlements. Understanding these differences is key to planning a cost-effective sandbox strategy.
| Sandbox Type | What It Includes | Storage | Refresh Cycle | Best For |
|---|---|---|---|---|
| Developer | All production metadata, no data. Included even in lower editions | ~200 MB data / 200 MB file | Daily | Individual development, unit testing |
| Developer Pro | Metadata-only like Developer, larger storage. Included with higher editions or add-on purchase | ~1 GB data / 1 GB file | Daily | Integration testing, larger dev tasks |
| Partial Copy | All metadata + subset of production data via Sandbox Template. Enterprise+ or add-on | Up to ~5 GB / 10,000 records per object | Every 5 days | QA with realistic data, integration testing |
| Full Copy | Complete replica of production (all data + metadata). Only included with Unlimited Edition | Full production data volume | Every 29 days | Final UAT, performance testing, staging |
| 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 |
Sandboxes utilise your existing user licences for access. Users log in with cloned accounts from production. You can activate or deactivate users independently of production to control access. No new Salesforce licence is consumed when a user accesses a sandbox. This means sandbox cost is driven by the sandbox type and quantity, not by user counts.
In addition to sandboxes, Salesforce provides Developer Edition (DE) orgs: free, standalone orgs useful for initial development and experimentation.
| Developer Edition Org Feature | Detail |
|---|---|
| Cost | Free. No licence required |
| Capabilities | Many Enterprise Edition features (custom objects, Apex, etc.) with strict limits. Very small data/storage allowance (a few MBs), typically 1-2 user accounts |
| Connection to production | Not connected to production org. Cannot be refreshed from production data |
| Use cases | Proof-of-concept, training, building AppExchange packages. Useful when sandbox capacity is constrained |
| Deployment | Moving components to production requires manual deployment (Metadata API, packages) |
Encourage early-stage development and innovation in Developer Edition orgs without consuming sandbox resources. An R&D team prototyping a new feature can use DE orgs until the concept is validated, then migrate the configuration into a proper sandbox for integration testing. This approach preserves your sandbox licences for QA, UAT, and staging where they deliver the most value.
Sandbox licences are finite resources that require active management. The following practices prevent sandbox sprawl and keep costly environments limited to when they are truly needed.
| Practice | Detail |
|---|---|
| Right-size your sandbox allocation | Match sandbox types to their purpose. Avoid using a Full Copy for daily development. Use Developer/Dev Pro for development and unit testing, Partial Copy for data-intensive QA, and reserve Full Copy for final UAT or staging |
| Avoid blanket sandbox access | Sandboxes should not be accessible to every production user. Limit active users to developers, admins, dedicated QA staff, and a subset of business testers for UAT. Deactivating unnecessary accounts reduces risk and protects sensitive data |
| 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 API calls. If all 500 production users log into a Full sandbox, the load could require additional resources. Keep user counts lean |
| Monitor and recycle environments | Treat sandbox licences as capacity to be managed. Plan usage schedules for each sandbox (project or testing cycle), then refresh or repurpose. Do not leave sandboxes idle. An unused sandbox still counts against your licence quota. Delete or archive completed project sandboxes to free slots |
| Review before renewal | Review sandbox usage before each Salesforce contract renewal. If you are not fully using a purchased Full Copy, negotiate to drop it (saving cost) or trade for additional Partial sandboxes. If teams are struggling without a Full sandbox, budget for the add-on but offset by right-sizing other environments |
| SDLC Stage | Recommended Sandbox | Purpose |
|---|---|---|
| Development | Developer / Dev Pro | Individual sandboxes per developer or team for isolated build and unit test |
| Integration QA | Dev Pro / Partial Copy | Shared sandbox where code from different developers is integrated and tested with broader dataset |
| UAT | Full Copy / Partial | Final validation by power users and stakeholders with realistic data volumes and configurations |
| Staging / Pre-Prod | Full Copy | Final performance tests and dry-run deployments. Many customers combine this with the UAT sandbox |
| Best Practice | Detail |
|---|---|
| Refresh cadence and data management | Coordinate sandbox refreshes with testing cycles. Refresh Full Copy just before UAT for up-to-date test data. Update Partial Copy templates for upcoming tests. Factor in refresh limits (monthly for Full) when planning timelines. Implement data masking for sandboxes containing sensitive production data |
| Licence efficiency in testing | Use the smallest sandbox that meets each stage's needs. For a test requiring 1,000 records, Partial Copy is more 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 |
| Collaboration and training | Sandboxes are useful for training users on new features before go-live. Partial or Full sandbox provides realistic data without affecting production. Limit training to specific users and timeframes. Plan whether a post-training refresh is needed before final UAT |
The overarching principle of sandbox strategy is to use the minimum environment necessary at each SDLC stage. Developer sandboxes for development, Partial Copy for QA, Full Copy only for final UAT and performance testing. This prevents sandbox sprawl, conserves licence entitlements, and ensures costly Full Copy environments are reserved for when they genuinely deliver value that lesser environments cannot.
| Case Study: Global Retailer (Enterprise Edition, ~200 Users) | Detail |
|---|---|
| Context | 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) for functional tests. Partial Copy refreshed with template (key objects up to 5 GB) for integration testing and super-user training. Full Copy reserved for final UAT, refreshed before major releases, with only ~20 users given access. After UAT sign-off, Full sandbox serves as staging for dress-rehearsal deployments |
| Result | By using Developer and Partial sandboxes for most dev/test cycles, the expensive Full Copy is only used when necessary. CIO keeps licensing cost contained (one Full add-on) and ensures it is fully utilised for critical testing |
| Case Study: Mid-Market Tech Firm (Professional Edition) | Detail |
|---|---|
| Context | Very limited included sandboxes (one Developer sandbox by default). No Full or Partial sandboxes included with Professional Edition |
| Strategy | Admin does initial build-out and unit testing in provided Developer sandbox. Two developers each set up free Developer Edition orgs for parallel experimentation. As components mature, deployed into the Developer sandbox for integration testing with manually loaded sample data. UAT conducted in production org during off-hours with test records as a controlled live pilot |
| Result | Constrained but creative approach. Delivered a tested solution with minimal sandbox resources. As the firm grows, plan to negotiate Enterprise Edition with included sandboxes and engage licensing adviser to optimise the contract |
| Step | Action | Detail |
|---|---|---|
| 1 | Inventory sandbox entitlements | Document the number of sandboxes of each type, your Salesforce edition, and associated contracts. Ensure you are aware of refresh limits and storage constraints for each sandbox |
| 2 | 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 |
| 3 | Optimise licence usage | Avoid over-provisioning sandboxes or users. Only purchase additional sandboxes (e.g. Full copies) if testing requirements clearly demand it. Use free Developer Edition orgs or share sandboxes when budget is tight |
| 4 | Control sandbox access | Implement governance on who can access each sandbox. Activate accounts only for testers and developers who need it. Protects data and reduces configuration drift risk |
| 5 | Plan refresh and data strategy | Plan refresh schedules in tandem with release cycles. Before major tests, refresh relevant sandboxes. Use Sandbox Templates for Partial Copy and consider data masking for sensitive information |
| 6 | 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? Review before renewals |
| 7 | 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 can identify opportunities to reduce cost or improve compliance |
The sandbox strategy must align with both technical needs and financial reality. Use free Developer Edition orgs for early prototyping. Use the smallest sandbox necessary at each stage. Reserve costly Full Copy sandboxes for when they are truly needed. Review sandbox allocation before every renewal to ensure your mix still matches your development lifecycle.
No. Sandboxes utilise your existing production user licences. Users log in with cloned accounts from production. No additional user licence fees apply for sandbox access. The cost of sandboxes is driven by the sandbox type and quantity, not by the number of users who access them.
Enterprise Edition includes Developer sandboxes and one Partial Copy sandbox. Developer Pro is available as an add-on. Full Copy sandboxes are not included and must be purchased separately at significant cost. Unlimited Edition includes all sandbox types, making it the most sandbox-rich edition.
Not entirely, but they are a valuable complement. Developer Edition orgs are free and useful for early prototyping, proof-of-concept work, and training. However, they are not connected to your production org, have very limited storage, and require manual deployment to move components. They work best for early-stage development before promoting code into proper sandboxes for integration testing and UAT.
Developer and Developer Pro sandboxes can be refreshed daily. Partial Copy sandboxes can be refreshed every 5 days. Full Copy sandboxes can be refreshed every 29 days. Factor these refresh limits into your testing timeline planning, especially for Full Copy environments where the monthly cycle constrains scheduling.
No. Full Copy sandboxes are overkill for daily development in both data volume and cost. Use Developer or Developer Pro sandboxes for individual development and unit testing. Reserve Full Copy for final UAT, performance testing with production-scale data, and staging/pre-production dry runs. This is the most common source of sandbox waste in enterprise Salesforce environments.
Implement data masking for any sandbox containing production data with sensitive information (PII, financial data, health records). Partial Copy sandboxes allow you to define Sandbox Templates that select specific record subsets, limiting exposure. For Full Copy sandboxes, use third-party data masking tools or Salesforce's built-in capabilities to anonymise sensitive fields after refresh.
Yes. Sandbox entitlements are negotiable, particularly for enterprise customers. If you need a Full Copy sandbox on Enterprise Edition, negotiate the add-on cost or trade sandbox entitlements against other concessions (additional sandboxes in lieu of other features, sandbox add-ons bundled at reduced cost during renewal). Review your sandbox mix before every renewal to optimise allocation.
An unused sandbox still counts against your licence quota. Salesforce will lock sandboxes that exceed your entitlement. Idle sandboxes waste resources and contribute to sandbox sprawl. Delete or archive completed project sandboxes to free up slots. Treat sandbox licences as finite capacity requiring active management, not as permanent allocations.
Salesforce contracts are complex. Sandbox entitlements, edition upgrades, user licence mix, and renewal terms all interact in ways that can cost or save significant money. Our Salesforce specialists help enterprises right-size sandbox allocations, negotiate favourable contract terms, and ensure licence compliance. 100% vendor-independent. Fixed-fee engagement.
Salesforce Advisory ServicesIndependent Salesforce licensing advisory. Sandbox allocation review. Contract negotiation. Edition optimisation. 100% vendor-independent, fixed-fee engagement.