Sandbox Templates
A sandbox template is a saved, reusable definition that tells Salesforce which objects' data to copy from production when you create or refresh a Partial Copy or Full sandbox.
Definition
A sandbox template is a saved, reusable definition that tells Salesforce which objects' data to copy from production when you create or refresh a Partial Copy or Full sandbox. Instead of cloning everything, you pick the objects you care about and Salesforce copies records only for those, keeping the sandbox smaller and faster to spin up.
Templates live in Setup and can be reused across many sandboxes. A Partial Copy sandbox always needs one, because that is how it limits itself to roughly 10,000 records per selected object and 5 GB of attachments. A Full sandbox can use a template too, through the Object Data Included setting, when you want a complete metadata copy but only a slice of the data.
How sandbox templates shape what gets copied
What a template actually controls
A sandbox template controls data, not configuration. Every sandbox already copies your full metadata, which means objects, fields, code, flows, page layouts, and profiles all come across regardless of any template. The template only governs which object records are pulled from production into the copy. You build it by selecting the objects you want, and Salesforce stores that selection so you can apply it again later. Think of it as a checklist of "copy rows from these tables, skip the rest." This matters because a Full sandbox without a template clones every record in production, which can take a long time and consume a large amount of storage. By naming only the objects your testing needs, you cut the copy down to a workable size. The same template can drive several different sandboxes, so a team can standardize on one definition rather than re-selecting objects each time. When the underlying data model changes, the template needs a look, since objects added after the template was built will not be copied unless you edit the template to include them.
Partial Copy versus Full, and where templates fit
Salesforce has four sandbox types, and only two of them use templates. Developer and Developer Pro sandboxes copy metadata and configuration but no production records, so there is nothing for a template to filter. A Partial Copy sandbox is the type built around templates. It requires one, and without a saved template the Create button does not even appear. The template caps the copy at about 10,000 records per selected object, plus their related child records, up to 5 GB of attachments total. Partial Copy sandboxes can be refreshed every 5 days. A Full sandbox is different. It is meant to be a near-replica of production and copies all data by default. You can still attach a template through the Object Data Included field, choosing Template-based instead of All, when you want the full metadata picture but a trimmed data set for performance or to keep sensitive records out. Full sandboxes refresh every 29 days, so a smaller data footprint also means a faster refresh cycle.
Related objects and data integrity
One of the more helpful behaviors of templates is how they handle relationships. When you add an object to a template, Salesforce automatically pulls in the records needed to keep that data valid. If you include Opportunity, the related Account and Contact records that those opportunities point to come along too, so you do not end up with orphaned records or broken lookups in the sandbox. This is why a Partial Copy sandbox is described as copying parent records and their related child records rather than a flat count. The practical takeaway is that a template rarely produces exactly the number of records you picked. Including one transactional object often drags in several supporting objects underneath it. That is usually what you want, since a Case with no Account behind it tells you very little during testing. It also means you should think in terms of object groups, not single objects. A template that copies orders but skips the products and price book entries behind them gives you data that looks real on the surface but fails the moment a flow or validation rule touches the missing pieces.
Why teams design templates carefully
The quality of a sandbox depends almost entirely on the quality of its template. A template that captures representative data gives testers an environment that behaves like production, where edge cases surface before they reach real users. A template that misses key objects produces a sandbox that passes tests it should fail, because the data that would have triggered a problem was never copied. Teams that take release management seriously treat templates as a maintained asset, reviewing them when the data model grows and version-controlling the intent behind them. There is also a privacy angle. A Full sandbox normally inherits every sensitive record from production, which many security and compliance teams will not allow for environments that more people can access. A template lets you copy only the objects that are safe to expose, or pair a slim copy with a data mask afterward. Getting the template right is a small upfront effort that pays back every time a developer or tester opens that environment expecting it to mirror real behavior.
Creating and refreshing with templates in practice
You manage templates in Setup, under the Sandboxes area, where a separate Sandbox Templates tab lets you create, edit, and delete them independent of any single sandbox. A template needs a name, an optional description, and at least one selected object. For a Partial Copy sandbox you build or pick the template during creation, and it is applied at copy time. For a Full sandbox you reach the same selection by setting Object Data Included to Template-based on the data step of the wizard. Refreshes follow the same logic. When you refresh a Partial Copy or template-driven Full sandbox, Salesforce re-applies the chosen template against current production data, so the refreshed environment reflects whatever the template defines today, not when it was first created. That is a feature, not a bug, but it surprises people who edited a template and forgot it would change the next refresh. It is also worth knowing that you can create a template with no object data at all, which produces a metadata-only Partial Copy when you want configuration without any records.
Templates in a modern DevOps pipeline
Sandbox templates predate the source-driven tooling most teams use now, but they still slot into that world. Salesforce DX and the sandbox definition file let you spin up sandboxes from the command line, and a sandbox definition can reference an existing template by id so automated environment creation reuses the same curated data set your admins built in the UI. That keeps continuous integration sandboxes consistent with what humans test against. Scratch orgs, by contrast, start empty and rely on synthetic data you load yourself, so templates do not apply there. The mental model that helps is matching the environment to the job. Use Developer or Developer Pro sandboxes for coding with no real data, a template-driven Partial Copy for integration and feature testing with a realistic slice, and a Full sandbox for staging and user acceptance testing where you want the closest thing to production. The template is the lever that turns the data volume up or down across that spectrum without changing the metadata that every sandbox already carries.
How to create and apply a sandbox template
You create a sandbox template once in Setup, then apply it whenever you create or refresh a Partial Copy or Full sandbox. The steps below assume you have the Modify All Data permission and available sandbox licenses.
- Open the Sandbox Templates tab
From Setup, enter Sandboxes in Quick Find and select Sandboxes, then open the Sandbox Templates tab. Click New Sandbox Template to start a fresh definition.
- Name the template and pick objects
Give the template a clear name and optional description. In the object list, check each object whose records you want copied. Salesforce auto-selects related objects needed to keep the data valid.
- Save and review the selection
Save the template. Revisit the object list to confirm you included supporting objects (products behind orders, accounts behind cases) so flows and validation rules have the data they expect.
- Apply it to a sandbox
When creating a Partial Copy sandbox, select this template on the data step. For a Full sandbox, set Object Data Included to Template-based and choose it. The template applies at copy and on every refresh.
A unique label for the template. Choose something that signals its purpose, such as Sales-UAT-Data, so teammates pick the right one.
The checklist of objects whose records get copied. Each selected object copies up to 10,000 records in a Partial Copy, plus related child records.
On a Full sandbox, choose All for every record or Template-based to apply this template and copy only the selected objects' data.
- A Partial Copy sandbox will not show a Create button until at least one template exists.
- Objects added to your org after the template was built are not copied until you edit the template to include them.
- Editing a template changes what the next refresh copies, which can surprise people who forgot they touched it.
- Record counts rarely match your picks exactly, because related parent and child records are pulled in automatically.
Trust & references
Cross-checked against the following references.
- Create or Edit Sandbox TemplatesSalesforce
- Sandbox Types and TemplatesSalesforce
Straight from the source - Salesforce's reference material on Sandbox Templates.
Hands-on resources to go deeper on Sandbox Templates.
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 are Sandbox Templates?
Q2. How many records per object?
Q3. Why design templates carefully?
Discussion
Loading discussion…