A buyer side guide to the four Salesforce sandbox types, the edition allocations, the refresh limits, and the moves that cut surplus Full and Partial Copy orgs before your renewal locks in.
Salesforce sandbox spend grows quietly as estates keep Partial Copy and Full orgs they no longer use. This playbook shows the four types, the edition allocations, the refresh limits, and the moves that cut surplus before renewal.
Salesforce sells sandboxes as included allocations plus paid add ons tied to your edition. The cost rarely appears as a single line. It hides inside the platform agreement and the annual uplift.
Most buyers never reconcile the sandboxes they pay for against the sandboxes they actually use. That gap is where the savings sit.
Key takeaways
They differ on storage, refresh interval, and whether they copy production data. Developer and Developer Pro are metadata orgs. Partial Copy carries a sample of data. Full is a complete production copy. The type sets both the cost and the refresh limit, as Salesforce documents in its sandbox types guidance.
Salesforce sandbox type comparison
| Type | Data copied | Refresh interval | Best use |
|---|---|---|---|
| Developer | Metadata only | 1 day | Coding and unit work |
| Developer Pro | Metadata only | 1 day | Larger build and test |
| Partial Copy | Sample data | 5 days | Integration and training |
| Full | Full production copy | 29 days | Staging and user acceptance |
Developer and Developer Pro orgs hold configuration and code, not production data. They refresh daily, so they suit active build work. They are the cheapest tier and rarely the source of overspend.
A Full sandbox refreshes only every 29 days, per the Salesforce sandbox refresh guidance. Teams that need fresher data more often tend to buy a second Full org rather than wait. That workaround, not the build need, is what inflates the count.
Each edition bundles a different sandbox allocation, and everything beyond the bundle is a paid add on. Confirm your entitlement against the order form and the Salesforce Platform editions and pricing page before you assume you are short.
A Partial Copy org earns its cost when you need realistic data for integration testing or training without a full production copy. It refreshes every 5 days and carries a sampled data set. Used for staging it is overkill, and a Full org is the wrong default there too.
Sandbox costs grow because orgs are easy to add and hard to retire. A project spins up a Full org, the project ends, and the org keeps renewing. Storage allocations and refresh add ons compound the drift, as Salesforce sets out in its data and file storage documentation.
Dormant orgs survive because nobody owns the inventory. Renewals are negotiated on the master, the sandbox line is treated as fixed, and no one maps orgs to active projects. The fix is an inventory tied to named owners and last login dates.
The moves below compound across the renewal cycle. Run them in order, finishing the internal rightsizing before you open the commercial conversation.
The standard account team pitch is to buy the largest sandbox bundle so developers never wait on a refresh. We disagree. Across the estates we benchmarked, the wait was almost never the real constraint, and the extra Full orgs sat idle between releases. Buying capacity to remove a rare bottleneck locks in a recurring cost against a one time problem. The buyer side move is to size the count to your real release cadence, solve genuine refresh pressure with scheduling rather than more orgs, and hold the surplus back as a concession the vendor has to earn at renewal.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
Redress reframed the conversation around the sandboxes we actually used, not the bundle Salesforce wanted us to hold. We cut the line by a quarter and lost nothing.Vice President, Salesforce Architecture, global SaaS group
The checklist below opens the buyer side sandbox conversation before the publisher locks the renewal anchor.
Developer, Developer Pro, Partial Copy, and Full. They differ on data copied, refresh interval, and cost, with Developer holding metadata only and Full holding a complete production copy.
A Full sandbox can refresh every 29 days. Teams that need fresher data more often tend to add a second Full org, which is the most common driver of sandbox overspend.
Yes. Enterprise, Unlimited, and Performance editions each bundle a different sandbox allocation. Anything beyond the included bundle is a paid add on purchased at standalone list price.
Most estates can cut the sandbox line by 15 to 30 percent at renewal. The savings come from retiring dormant orgs, rebalancing types, and dropping unused refresh add ons.
Start nine to twelve months before the contract end date. Use the first six months to rightsize internally, then open the commercial conversation in the final stretch.
Often a Partial Copy sandbox is enough for staging and training. A Full org is the right default only when you need a complete production copy for user acceptance testing.
Pull last login and activity data for every org and flag any sandbox idle for 90 days. Tie each org to a named owner and a live project before renewal.
Yes, and it should be. Aligning sandbox renewal dates with Sales Cloud and Service Cloud creates a single negotiation event and stronger aggregation leverage.
The buyer side moves across editions, sandboxes, add ons, and the renewal uplift, sequenced for the twelve months before your contract end date.
Used across more than five hundred enterprise software engagements. Independent. Buyer side.
We work for the buyer. Always. There is no other side of our table.
Salesforce sandbox signals, edition allocation signals, refresh and storage signals, and the broader Salesforce licensing leverage signals.
