Full Sandbox
A Full Sandbox is the largest of the Salesforce sandbox types, copying both the production org's metadata (every customization, every configuration) and the production data (every record across every object) into a separate, fully functional environment.
Definition
A Full Sandbox is the largest of the Salesforce sandbox types, copying both the production org's metadata (every customization, every configuration) and the production data (every record across every object) into a separate, fully functional environment. Unlike smaller sandbox types that copy metadata only or include limited data samples, the Full Sandbox is a complete replica intended for production-mirror testing scenarios: integration testing with realistic data volumes, performance testing against actual record counts, user acceptance testing with familiar production-like data, and pre-production validation of major changes.
The Full Sandbox is licensed at the Enterprise tier and above with one Full Sandbox typically included; additional Full Sandboxes are purchased per unit. Refresh cadence is the longest of any sandbox type: a Full Sandbox can be refreshed only once every 29 days, reflecting the resource cost of copying terabytes of production data. The setup process can take hours to days depending on org size. Most enterprises use the Full Sandbox sparingly, reserving it for the final pre-production validation window and using lighter sandboxes for day-to-day development.
When and how to use a Full Sandbox
Sandbox types and what each copies
Salesforce offers four sandbox types. Developer Sandbox: metadata only, no data. Developer Pro: metadata plus a small fixed data sample. Partial Copy: metadata plus a configurable subset of data (rows per object capped at 10,000). Full Sandbox: metadata plus all production data. The trade-off is realism versus refresh speed and cost. Full is the most realistic but also the slowest to refresh and the most resource-intensive.
Refresh cadence and timing
Full Sandbox refresh is capped at once every 29 days. The refresh process itself takes hours to several days for large orgs, during which the sandbox is unavailable. Plan refresh timing carefully: refreshing during a release validation window disrupts QA, but waiting too long leaves the sandbox with stale data that does not reflect current production. Most teams schedule the refresh just before the start of a major test cycle.
Sandbox templates and data subsetting
Full Sandbox supports Sandbox Templates that let you select which objects' data to copy. This is useful when the full data set is overwhelming but you still want production volumes on specific objects (Opportunity, Account, Case). The template defines included objects; data outside the template is omitted. Plan the template carefully because changing it requires a new refresh.
Post-refresh setup steps
Every Full Sandbox refresh requires post-refresh setup: re-enable email deliverability (sandboxes default to System Email Only after refresh), update integration endpoints (sandbox URLs differ from production), reset Connected App secrets, anonymize sensitive data if compliance requires. Build a runbook of post-refresh steps and assign an owner; without one, the first user to hit the sandbox finds it broken in mysterious ways.
Data masking and compliance
Production data in a Full Sandbox is real customer data subject to the same compliance requirements as production. For GDPR, HIPAA, or PCI-regulated orgs, this is a serious concern. Use Sandbox Templates to exclude sensitive objects, write post-refresh anonymization scripts, or use the Data Mask feature (part of Salesforce Shield) to scramble sensitive fields after refresh. Compliance officers should sign off on the sandbox handling process.
Storage and licensing
Each Full Sandbox consumes storage equal to production at the time of refresh. Storage caps apply but are typically generous; most orgs do not hit them. Licensing: Enterprise Edition includes one Full Sandbox; additional Full Sandboxes are purchased per unit and licensed annually. Confirm available units in Setup > Sandboxes before promising a Full Sandbox to a project.
Use cases where Full Sandbox is the right tool
Reserve Full Sandbox for: pre-production validation of large releases, performance testing against production-volume data, integration testing with real downstream record counts, user acceptance testing where realistic data makes the difference, and data migration rehearsals. For day-to-day development, lighter sandboxes (Developer or Partial Copy) are faster to refresh and cheaper to run. Do not use Full for unit testing or routine config changes.
Create or refresh a Full Sandbox
Creating or refreshing a Full Sandbox is a planned event because of the time and resource cost. The steps below cover the safe approach for a first-time setup and an ongoing refresh cadence.
- Confirm available Full Sandbox units
Setup > Sandboxes. Check the Available counter for Full Sandboxes. If at zero, the org needs to purchase additional units before proceeding.
- Plan the Sandbox Template
Decide whether to copy all data or use a template to subset specific objects. Templates are valuable when full data is overwhelming or compliance-sensitive.
- Schedule the refresh window
Pick a window when the sandbox is not actively in use. Full refresh can take hours to days; plan for the worst case.
- Initiate the refresh
From Setup > Sandboxes, click Refresh next to the existing Full Sandbox or click Create for a new one. Select the template if applicable. Confirm.
- Monitor progress
The Sandbox list shows refresh status. Email notification fires on completion. Do not assume the sandbox is ready until the notification arrives.
- Run post-refresh setup
Execute the runbook: enable email deliverability, update integration endpoints, reset Connected App secrets, run data anonymization scripts. Each step is documented in advance, not invented during the rush.
- Hand off to project team
Notify the project team the sandbox is ready. Provide access credentials, test data references, and any caveats specific to this refresh.
Complete metadata and data copy. Largest, slowest refresh, most realistic.
Configuration subset for selective data copy. Useful for compliance or performance.
Once every 29 days for Full. Plan release timing around this cap.
Resets to System Email Only. Must be re-enabled to All Email for most testing.
Shield product that anonymizes sensitive fields. Run after refresh for compliance-sensitive orgs.
- Refresh cadence is 29 days minimum. Plan release schedule around this; you cannot refresh more often.
- Post-refresh setup is required. Email defaults to System Only, integrations point to wrong endpoints, secrets reset. Sandbox is broken until runbook executes.
- Production data is regulated data. Sandbox is not exempt from GDPR, HIPAA, or PCI; plan anonymization before users access.
- Full refresh can take days for large orgs. Schedule with substantial buffer; rush jobs produce broken sandboxes.
- Full Sandbox units are licensed separately at most editions. Confirm availability before committing the sandbox to a project.
Trust & references
Straight from the source - Salesforce's reference material on Full Sandbox.
- Configuring Full SandboxesSalesforce Help
- Create, Clone, or Refresh a SandboxSalesforce Help
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 Full Sandbox copy?
Q2. What's the Full Sandbox refresh interval?
Q3. What are typical use cases for Full Sandboxes?
Discussion
Loading discussion…