Cluster IV · Article xxi of forty

Sandbox licensing.

Salesforce ships four sandbox tiers (Developer, Developer Pro, Partial Copy, and Full) and a published per-edition allocation that determines what comes bundled and what is purchased incrementally. The Admodum read on the sandbox-tier surface, the allocation table, the refresh interval, the storage profile, the data-mask architecture, and the buyer-side rationalisation discipline.

ClusterSalesforce
Read13 minutes
AuthorKaren E. Whitfield
PublishedQ2 2026

Key takeaways

Section i

The four sandbox tiers.

Salesforce ships four sandbox tiers. The Developer sandbox is the lightest tier and holds metadata only with two hundred megabytes of data storage and a once-daily refresh interval. The Developer Pro sandbox holds metadata only with one gigabyte of data storage and a once-daily refresh interval. The Partial Copy sandbox holds metadata plus a sample of production data with five gigabytes of data storage and a five-day minimum refresh interval. The Full sandbox holds metadata plus a full copy of production data with storage matching the production org and a twenty-nine-day minimum refresh interval.

The four tiers serve different layers of the release pipeline. The Developer and Developer Pro sandboxes hold the per-developer feature-branch and unit-test environments. The Partial Copy sandbox holds the integration-test and user-acceptance-test environment with realistic data volumes. The Full sandbox holds the staging environment for production-equivalent regression test, performance benchmark, and pre-release sign-off. The pipeline architecture is the principal architectural decision facing the customer relationship management programme owner.

Section ii

The per-edition allocation table.

Sandbox allocation is bundled with the underlying CRM edition. Enterprise Edition ships a published baseline allocation including a Developer sandbox plus a published count of Developer Pro and Partial Copy sandboxes. Unlimited Edition ships a richer allocation including a Full sandbox plus a richer count of the lower-tier sandboxes. Incremental sandboxes above the bundled allocation are purchased at the published list price per tier.

The realised closing band on incremental sandboxes is contract-by-contract and reflects the contracted CRM-edition mix, the deployed sandbox inventory, and the wider commercial position. The wider Sales Cloud editions and Service Cloud editions spokes hold the underlying CRM-edition allocation read.

The sandbox is the release-pipeline environment. The four tiers (Developer, Developer Pro, Partial Copy, Full) map directly to the four layers of a healthy release pipeline.
Section iii

The refresh interval and storage profile.

The refresh interval is the minimum gap between two consecutive refreshes against the same sandbox. The Developer and Developer Pro sandboxes refresh once daily; the Partial Copy sandbox refreshes every five days; the Full sandbox refreshes every twenty-nine days. The interval constrains the release-pipeline cadence and shapes how the Partial Copy and Full sandboxes are scheduled against the platform release train and the customer release cadence.

The storage profile constrains the data-volume sample that can be loaded into each tier. The Developer sandbox carries two hundred megabytes; the Developer Pro sandbox carries one gigabyte; the Partial Copy sandbox carries five gigabytes; the Full sandbox carries the production-equivalent storage profile. The wider Data Cloud credits spoke reads the related storage-economics topic on the Data Cloud surface, and the underlying production storage allocation reads against the platform data-storage discipline.

Section iv

The data-mask architecture.

Sandbox data is governed by the same data-privacy and data-classification rules as the production org. Personal data copied from production into a sandbox carries the same data-protection obligations, and the discipline reads the personal-data fields against the sandbox population. Salesforce ships a Data Mask managed package that applies anonymisation rules at the sandbox-refresh cadence, replacing the personal-data field values with masked or pseudonymised equivalents while preserving the structural relationships across the data model.

The data-mask architecture is the principal architectural decision facing the data-protection officer on a Partial Copy or Full sandbox. The masking rules read the personal-data inventory across the standard and custom objects, the cross-object relationships, the integration footprint, and the data-residency position. The architectural read sits inside the wider data-protection-by-design discipline that applies to every Salesforce deployment.

Section v

The renewal cycle and the incremental-sandbox position.

The Salesforce sandbox renewal cycle aligns with the wider master subscription agreement. The renewal-cycle artefact reads the deployed sandbox inventory against the bundled per-edition allocation, the deployment-cohort sandbox utilisation, the per-tier list-step the publisher carries on incremental sandboxes, and the realised closing band drawn from the firm's Benchmarking library on the platform cluster.

The renewal-evidence pack carries four artefacts on the sandbox surface. The bundled per-edition allocation against the deployed sandbox count. The incremental-sandbox population against the release-pipeline cadence. The data-mask architecture position against the Partial Copy and Full sandboxes. The renewal posture against the publisher's per-tier list-step. The pack is the closing position transmitted to the publisher inside the Renewal Programme cycle, countersigned by a second partner.

Section vi

The commitment-design discipline.

The commitment-design discipline reads four artefacts at the buyer-side commercial level: the deployed sandbox inventory against the bundled per-edition allocation across the production-org footprint; the release-pipeline cadence against the four-tier sandbox architecture; the data-mask architecture position against the Partial Copy and Full sandbox refresh interval; the renewal-cycle posture against the publisher's per-tier list-step on incremental sandboxes.

The senior-advisor read produces the renewal evidence pack and the closing-band benchmark drawn from the firm's Benchmarking library on the platform cluster. The discipline aligns the sandbox commitment to the realised release-pipeline architecture rather than to the Salesforce account-team's full-deployment forecast on the platform overlay. The wider seat-reassignment policy spoke reads the discipline on the user-management surface.

More from the Salesforce cluster

Continue the reading.

Article i

Sales Cloud editions

The underlying CRM-edition ladder that determines the bundled sandbox allocation.

Article ii

Service Cloud editions

The customer-service CRM-edition ladder that determines its bundled sandbox allocation.

Article xii

Seat reassignment policy

The named-user evidence discipline that frames the production-side commitment.

Engage

Read your Sandbox licensing commitment with a senior advisor.

A senior Admodum Salesforce advisor will read your sandbox-tier inventory, your bundled per-edition allocation, your release-pipeline cadence and your data-mask architecture on a private call. Active renewal moments route to Renewal Programme.

Vendor Intelligence Monthly

One monthly briefing on Salesforce pricing moves, contract precedents and negotiation windows. Written by the advisors who run the engagements. No marketing list.

Subscribe to the briefing
Independence
Admodum is not a partner, reseller, or affiliate of Salesforce, or of any other software vendor. No reseller margin, no referral commission, no audit-subcontract relationship.