Sandbox Types and Refresh Considerations
5 minutes
5 Questions
Salesforce offers four sandbox types, each suited to different stages of the development lifecycle. Developer sandboxes copy only metadata (configuration, code) with 200 MB of data storage and can be refreshed once per day; they are ideal for individual development and unit testing. Developer Pro sandboxes also copy metadata only but provide 1 GB of storage, supporting larger datasets for development and quality assurance; they too refresh daily. Partial Copy sandboxes include metadata plus a sample of production data defined by a sandbox template (up to 10,000 records per object, 5 GB total) and can be refreshed every 5 days; they are well suited for integration testing, user acceptance testing, and training. Full sandboxes replicate production entirely, including all data, attachments, and optionally field history and Chatter data, with storage matching production; they refresh every 29 days and are used for performance testing, load testing, and staging final deployments. Refresh considerations are critical for administrators. Refreshing replaces the sandbox with a fresh copy of production, so any unmigrated changes in the sandbox are lost; always deploy or back up work (via change sets, packages, or source control) before refreshing. Refresh intervals limit how often you can resynchronize, so plan timing carefully around release cycles. Sandbox templates let you control which objects are copied into Partial and Full sandboxes, reducing refresh time. Post-refresh tasks often include re-enabling integrations, updating endpoints, and adjusting email deliverability since sandboxes default to System Email Only. User email addresses are modified with '.invalid' appended, and usernames gain the sandbox name suffix. Consider data masking for sensitive information in sandboxes that contain production data. Apex classes can run automatically after refresh using the SandboxPostCopy interface to automate setup. Finally, sandbox licenses vary by edition, so verify availability before planning environment strategy.
Sandbox Types and Refresh Considerations: A Complete Guide for the Salesforce Advanced Administrator Exam
Why Sandbox Types and Refresh Considerations Matter
Every change you make to a Salesforce org carries risk. A misconfigured validation rule, a flow that fires in an unexpected order, or a bulk data load that goes wrong can disrupt the business immediately if it is done directly in production. Sandboxes exist to remove that risk by giving administrators, developers, and testers isolated copies of production where they can build, break, and fix things safely.
For the Advanced Administrator, this topic falls under Environment Management and Deployment, and it is tested because choosing the wrong sandbox type wastes money, slows down projects, and can make testing meaningless. Choosing the right type, understanding what gets copied, and planning refreshes carefully are hallmarks of a mature release management practice. Exam questions in this area are almost always scenario-based: you are given a business need and must pick the sandbox type or refresh approach that fits best.
What Is a Sandbox?
A sandbox is a copy of your production org that lives on a separate Salesforce instance. It is accessed through test.salesforce.com rather than login.salesforce.com. Sandboxes always contain a copy of your production metadata (configuration such as objects, fields, page layouts, flows, Apex, profiles, and permission sets). Whether they also contain data, and how much, depends on the sandbox type.
Sandboxes are provisioned as licenses attached to your production edition. Enterprise, Unlimited, and Performance editions come with different allocations, and additional sandbox licenses can be purchased. You create, refresh, clone, and delete sandboxes from Setup → Sandboxes, and you need the Manage Sandboxes permission to do so.
The Four Sandbox Types
1. Developer Sandbox
• Copies: metadata only (no production records)
• Data storage: 200 MB
• File storage: 200 MB
• Refresh interval: once per day
• Best for: individual developers or admins building and unit-testing configuration or code in isolation
2. Developer Pro Sandbox
• Copies: metadata only
• Data storage: 1 GB
• File storage: 1 GB
• Refresh interval: once per day
• Best for: development and quality assurance tasks that need larger manually loaded or generated data sets than a Developer sandbox can hold
3. Partial Copy Sandbox
• Copies: metadata plus a sample of production data
• Data storage: 5 GB
• File storage: 5 GB
• Refresh interval: once every 5 days
• Requires a sandbox template that specifies which objects to include; Salesforce copies up to 10,000 records per selected object
• Best for: user acceptance testing (UAT), integration testing, and training where realistic data is needed but a full copy is unnecessary
4. Full Sandbox
• Copies: all metadata and all production data (records, attachments, files)
• Data and file storage: same as production
• Refresh interval: once every 29 days
• Sandbox template is optional; you can also choose how much field history to copy (up to 180 days) and whether to include Chatter data
• Best for: performance testing, load testing, staging, and final pre-release validation with a true replica of production
Quick comparison memory aid:
Developer = 200 MB, 1 day, no data
Developer Pro = 1 GB, 1 day, no data
Partial Copy = 5 GB, 5 days, sample data via template
Full = production size, 29 days, all data
How Sandbox Templates Work
A sandbox template lets you define exactly which objects (standard and custom) are copied into a Partial Copy or Full sandbox. Templates are required for Partial Copy and optional for Full. When you select an object, Salesforce automatically includes required parent objects so that relationships remain intact. Templates are useful for limiting a Full sandbox to only the objects needed for a specific test, which speeds up the copy and reduces noise. Templates are not available for Developer or Developer Pro sandboxes because those types do not copy data.
How Refreshing Works
Refreshing a sandbox replaces its current contents with a fresh copy of production. The process:
1. You click Refresh next to the sandbox in Setup. For Partial Copy and Full sandboxes you confirm or change the template and data options.
2. Salesforce queues the copy. Developer sandboxes usually complete in minutes to hours; Full sandboxes can take several days depending on data volume.
3. When the copy is complete, the sandbox is in a Pending Activation state. Your existing sandbox is still usable until you activate.
4. You click Activate. This permanently deletes the old sandbox and replaces it with the new copy. Anything not saved elsewhere is lost.
You can only refresh after the refresh interval for that type has elapsed since the last refresh or creation. The interval is per sandbox, not per org.
What Happens to Users and Email on Refresh
• All production users are copied with their licenses, profiles, and permission sets.
• Usernames are modified by appending the sandbox name (for example, jane@acme.com becomes jane@acme.com.uat).
• User email addresses are modified by appending .invalid so that no real emails are accidentally sent to customers or employees from the sandbox.
• Email deliverability is set to System email only by default. You must change it to All email to test outbound email, and you must fix email addresses for the users who need to receive messages.
• Passwords: users who exist in production can log in with their production password at the time of the copy; new users created in the sandbox get sandbox-only credentials.
Key Refresh Considerations
Data loss. Everything built or loaded in the sandbox since the last refresh is destroyed on activation. Before refreshing, retrieve unfinished metadata (change sets, Salesforce CLI, DevOps Center, or version control) and export any test data you want to keep.
Timing and release windows. Sandboxes sit on either preview or non-preview instances during Salesforce release cycles. If you want to test an upcoming release early, your sandbox must be on a preview instance before the preview window starts; refreshing at the wrong time can move a sandbox out of (or into) the preview release. Always check the Salesforce sandbox preview instructions before scheduling a refresh around a release.
Integrations. Remote Site Settings, Named Credentials, Connected Apps, and outbound message endpoints are copied from production. After a refresh you must re-point integrations to test endpoints so your sandbox does not write to live external systems. Likewise, any external system pointing to the sandbox may need updated credentials because the sandbox org ID can change on refresh.
Scheduled jobs and automation. Scheduled Apex, scheduled flows, and reports subscriptions are copied. Review and pause anything that should not run in a test environment.
Record IDs. In Partial Copy and Full sandboxes, copied records keep the same IDs as production. Metadata component IDs are also preserved across all types. This matters when hard-coded IDs exist in formulas or code (which is a bad practice the exam may expect you to recognize).
Post-copy automation. You can specify an Apex class that implements the SandboxPostCopy interface when creating or refreshing a sandbox. Salesforce runs it automatically after the copy to perform tasks such as fixing email addresses for a test team, updating endpoints, or masking data.
Data privacy. Full and Partial Copy sandboxes contain real customer data. Consider masking or scrambling sensitive fields (Salesforce Data Mask is a paid option) and restrict who has access.
Storage. Developer and Developer Pro sandboxes have fixed storage limits. If you need to load a large test data set, choose Developer Pro or Partial Copy rather than hitting limits in a Developer sandbox.
Cloning. You can clone an existing sandbox to a new sandbox of the same license type. The clone copies the sandbox (including its data and in-progress work), not production. This is useful when a team wants a snapshot of a configured environment without waiting for a refresh interval.
Deleting. Deleting a sandbox frees the license so a new sandbox of that type can be created. Deletion is permanent.
Typical Sandbox Strategy (Release Pipeline)
Developer or Developer Pro (build) → Partial Copy or Developer Pro (QA / integration test) → Partial Copy (UAT and training) → Full (staging, performance testing, final regression) → Production.
Not every org needs every stage, but the exam expects you to understand that higher-fidelity environments sit closer to production and are refreshed less often.
Exam Tips: Answering Questions on Sandbox Types and Refresh Considerations
Tip 1 – Map the key phrase to the type.
• Performance testing, load testing, full data set, staging, exact replica → Full Sandbox
• Representative sample of data, UAT, training, 10,000 records per object, template required → Partial Copy
• Individual developer, unit testing, metadata only, daily refresh → Developer
• Development needing a larger data set, QA with loaded data, 1 GB → Developer Pro
Tip 2 – Memorize the numbers. Refresh intervals (1 / 1 / 5 / 29 days) and storage (200 MB / 1 GB / 5 GB / production) are the most frequently tested facts. If a question says a team must refresh weekly with real data, Partial Copy fits; if they ask for a refresh twice a month with all data, a Full sandbox cannot do it.
Tip 3 – Templates only apply to data-bearing sandboxes. If an answer mentions a sandbox template with a Developer or Developer Pro sandbox, it is wrong.
Tip 4 – Refresh equals wipe. Any scenario about losing work, losing test data, or needing to preserve configuration before a refresh points to backing up metadata (change sets, source control, CLI) and exporting data before activating the refreshed sandbox. Remember that the old sandbox survives until you click Activate.
Tip 5 – Email and username changes are default behavior. If users cannot receive emails from a sandbox, the answer involves the .invalid suffix and the System email only deliverability setting, not a bug. If users cannot log in, remember the username has the sandbox name appended and the URL is test.salesforce.com.
Tip 6 – Watch for integration and release timing distractors. Questions about external systems after a refresh test whether you know endpoints and credentials copy over and must be reviewed. Questions about testing a new Salesforce release test whether you know about preview versus non-preview instances and refreshing before the preview window.
Tip 7 – Cost and fidelity trade-off. When two answers could work, the exam usually prefers the least expensive sandbox that fully meets the requirement. Do not pick Full for a task that Partial Copy or Developer Pro handles.
Tip 8 – Automation after copy. If a question asks how to automatically update endpoints or user emails every time a sandbox is refreshed, the answer is an Apex class implementing SandboxPostCopy, not a manual checklist.
Tip 9 – Clone versus refresh. Cloning copies a sandbox to a new sandbox of the same type; refreshing copies production into the same sandbox. If the scenario wants to duplicate an in-progress environment for another team, clone it.
Tip 10 – Eliminate absolutes. Answers claiming that sandboxes copy production data in all cases, that refresh intervals can be overridden, or that templates work with any sandbox type are incorrect.
Master the four types, the four refresh intervals, what gets copied, and what changes on refresh, and you will be well prepared for every Sandbox Types and Refresh Considerations question on the Advanced Administrator exam.
Every change you make to a Salesforce org carries risk. A misconfigured validation rule, a flow that fires in an unexpected order, or a bulk data load that goes wrong can disrupt the business immediately if it is done directly in production. Sandboxes exist to remove that risk by giving administrators, developers, and testers isolated copies of production where they can build, break, and fix things safely.
For the Advanced Administrator, this topic falls under Environment Management and Deployment, and it is tested because choosing the wrong sandbox type wastes money, slows down projects, and can make testing meaningless. Choosing the right type, understanding what gets copied, and planning refreshes carefully are hallmarks of a mature release management practice. Exam questions in this area are almost always scenario-based: you are given a business need and must pick the sandbox type or refresh approach that fits best.
What Is a Sandbox?
A sandbox is a copy of your production org that lives on a separate Salesforce instance. It is accessed through test.salesforce.com rather than login.salesforce.com. Sandboxes always contain a copy of your production metadata (configuration such as objects, fields, page layouts, flows, Apex, profiles, and permission sets). Whether they also contain data, and how much, depends on the sandbox type.
Sandboxes are provisioned as licenses attached to your production edition. Enterprise, Unlimited, and Performance editions come with different allocations, and additional sandbox licenses can be purchased. You create, refresh, clone, and delete sandboxes from Setup → Sandboxes, and you need the Manage Sandboxes permission to do so.
The Four Sandbox Types
1. Developer Sandbox
• Copies: metadata only (no production records)
• Data storage: 200 MB
• File storage: 200 MB
• Refresh interval: once per day
• Best for: individual developers or admins building and unit-testing configuration or code in isolation
2. Developer Pro Sandbox
• Copies: metadata only
• Data storage: 1 GB
• File storage: 1 GB
• Refresh interval: once per day
• Best for: development and quality assurance tasks that need larger manually loaded or generated data sets than a Developer sandbox can hold
3. Partial Copy Sandbox
• Copies: metadata plus a sample of production data
• Data storage: 5 GB
• File storage: 5 GB
• Refresh interval: once every 5 days
• Requires a sandbox template that specifies which objects to include; Salesforce copies up to 10,000 records per selected object
• Best for: user acceptance testing (UAT), integration testing, and training where realistic data is needed but a full copy is unnecessary
4. Full Sandbox
• Copies: all metadata and all production data (records, attachments, files)
• Data and file storage: same as production
• Refresh interval: once every 29 days
• Sandbox template is optional; you can also choose how much field history to copy (up to 180 days) and whether to include Chatter data
• Best for: performance testing, load testing, staging, and final pre-release validation with a true replica of production
Quick comparison memory aid:
Developer = 200 MB, 1 day, no data
Developer Pro = 1 GB, 1 day, no data
Partial Copy = 5 GB, 5 days, sample data via template
Full = production size, 29 days, all data
How Sandbox Templates Work
A sandbox template lets you define exactly which objects (standard and custom) are copied into a Partial Copy or Full sandbox. Templates are required for Partial Copy and optional for Full. When you select an object, Salesforce automatically includes required parent objects so that relationships remain intact. Templates are useful for limiting a Full sandbox to only the objects needed for a specific test, which speeds up the copy and reduces noise. Templates are not available for Developer or Developer Pro sandboxes because those types do not copy data.
How Refreshing Works
Refreshing a sandbox replaces its current contents with a fresh copy of production. The process:
1. You click Refresh next to the sandbox in Setup. For Partial Copy and Full sandboxes you confirm or change the template and data options.
2. Salesforce queues the copy. Developer sandboxes usually complete in minutes to hours; Full sandboxes can take several days depending on data volume.
3. When the copy is complete, the sandbox is in a Pending Activation state. Your existing sandbox is still usable until you activate.
4. You click Activate. This permanently deletes the old sandbox and replaces it with the new copy. Anything not saved elsewhere is lost.
You can only refresh after the refresh interval for that type has elapsed since the last refresh or creation. The interval is per sandbox, not per org.
What Happens to Users and Email on Refresh
• All production users are copied with their licenses, profiles, and permission sets.
• Usernames are modified by appending the sandbox name (for example, jane@acme.com becomes jane@acme.com.uat).
• User email addresses are modified by appending .invalid so that no real emails are accidentally sent to customers or employees from the sandbox.
• Email deliverability is set to System email only by default. You must change it to All email to test outbound email, and you must fix email addresses for the users who need to receive messages.
• Passwords: users who exist in production can log in with their production password at the time of the copy; new users created in the sandbox get sandbox-only credentials.
Key Refresh Considerations
Data loss. Everything built or loaded in the sandbox since the last refresh is destroyed on activation. Before refreshing, retrieve unfinished metadata (change sets, Salesforce CLI, DevOps Center, or version control) and export any test data you want to keep.
Timing and release windows. Sandboxes sit on either preview or non-preview instances during Salesforce release cycles. If you want to test an upcoming release early, your sandbox must be on a preview instance before the preview window starts; refreshing at the wrong time can move a sandbox out of (or into) the preview release. Always check the Salesforce sandbox preview instructions before scheduling a refresh around a release.
Integrations. Remote Site Settings, Named Credentials, Connected Apps, and outbound message endpoints are copied from production. After a refresh you must re-point integrations to test endpoints so your sandbox does not write to live external systems. Likewise, any external system pointing to the sandbox may need updated credentials because the sandbox org ID can change on refresh.
Scheduled jobs and automation. Scheduled Apex, scheduled flows, and reports subscriptions are copied. Review and pause anything that should not run in a test environment.
Record IDs. In Partial Copy and Full sandboxes, copied records keep the same IDs as production. Metadata component IDs are also preserved across all types. This matters when hard-coded IDs exist in formulas or code (which is a bad practice the exam may expect you to recognize).
Post-copy automation. You can specify an Apex class that implements the SandboxPostCopy interface when creating or refreshing a sandbox. Salesforce runs it automatically after the copy to perform tasks such as fixing email addresses for a test team, updating endpoints, or masking data.
Data privacy. Full and Partial Copy sandboxes contain real customer data. Consider masking or scrambling sensitive fields (Salesforce Data Mask is a paid option) and restrict who has access.
Storage. Developer and Developer Pro sandboxes have fixed storage limits. If you need to load a large test data set, choose Developer Pro or Partial Copy rather than hitting limits in a Developer sandbox.
Cloning. You can clone an existing sandbox to a new sandbox of the same license type. The clone copies the sandbox (including its data and in-progress work), not production. This is useful when a team wants a snapshot of a configured environment without waiting for a refresh interval.
Deleting. Deleting a sandbox frees the license so a new sandbox of that type can be created. Deletion is permanent.
Typical Sandbox Strategy (Release Pipeline)
Developer or Developer Pro (build) → Partial Copy or Developer Pro (QA / integration test) → Partial Copy (UAT and training) → Full (staging, performance testing, final regression) → Production.
Not every org needs every stage, but the exam expects you to understand that higher-fidelity environments sit closer to production and are refreshed less often.
Exam Tips: Answering Questions on Sandbox Types and Refresh Considerations
Tip 1 – Map the key phrase to the type.
• Performance testing, load testing, full data set, staging, exact replica → Full Sandbox
• Representative sample of data, UAT, training, 10,000 records per object, template required → Partial Copy
• Individual developer, unit testing, metadata only, daily refresh → Developer
• Development needing a larger data set, QA with loaded data, 1 GB → Developer Pro
Tip 2 – Memorize the numbers. Refresh intervals (1 / 1 / 5 / 29 days) and storage (200 MB / 1 GB / 5 GB / production) are the most frequently tested facts. If a question says a team must refresh weekly with real data, Partial Copy fits; if they ask for a refresh twice a month with all data, a Full sandbox cannot do it.
Tip 3 – Templates only apply to data-bearing sandboxes. If an answer mentions a sandbox template with a Developer or Developer Pro sandbox, it is wrong.
Tip 4 – Refresh equals wipe. Any scenario about losing work, losing test data, or needing to preserve configuration before a refresh points to backing up metadata (change sets, source control, CLI) and exporting data before activating the refreshed sandbox. Remember that the old sandbox survives until you click Activate.
Tip 5 – Email and username changes are default behavior. If users cannot receive emails from a sandbox, the answer involves the .invalid suffix and the System email only deliverability setting, not a bug. If users cannot log in, remember the username has the sandbox name appended and the URL is test.salesforce.com.
Tip 6 – Watch for integration and release timing distractors. Questions about external systems after a refresh test whether you know endpoints and credentials copy over and must be reviewed. Questions about testing a new Salesforce release test whether you know about preview versus non-preview instances and refreshing before the preview window.
Tip 7 – Cost and fidelity trade-off. When two answers could work, the exam usually prefers the least expensive sandbox that fully meets the requirement. Do not pick Full for a task that Partial Copy or Developer Pro handles.
Tip 8 – Automation after copy. If a question asks how to automatically update endpoints or user emails every time a sandbox is refreshed, the answer is an Apex class implementing SandboxPostCopy, not a manual checklist.
Tip 9 – Clone versus refresh. Cloning copies a sandbox to a new sandbox of the same type; refreshing copies production into the same sandbox. If the scenario wants to duplicate an in-progress environment for another team, clone it.
Tip 10 – Eliminate absolutes. Answers claiming that sandboxes copy production data in all cases, that refresh intervals can be overridden, or that templates work with any sandbox type are incorrect.
Master the four types, the four refresh intervals, what gets copied, and what changes on refresh, and you will be well prepared for every Sandbox Types and Refresh Considerations question on the Advanced Administrator exam.
Test mode:
Admin II - Sandbox Types and Refresh Considerations Example Questions
Test your knowledge of Sandbox Types and Refresh Considerations
Question 1
Cloud Kicks refreshed its Full sandbox so testers could validate a new approval process. Each tester updated the email address on their own sandbox user record and confirmed the change. Password reset emails now reach the testers. Approval assignment emails and flow email alerts still do not arrive. The administrator confirms that the approval process and the flow are active. What explains this behavior?
Question 2
When a Partial Copy sandbox is created or refreshed, what does the sandbox template applied to it determine?
Question 3
Universal Containers is testing a new Opportunity flow. Testers need realistic production Accounts, Contacts, and Opportunities, and they want a fresh copy of that data before each weekly test cycle. The company's existing Full sandbox is reserved for a month-long training program, and the test data volume is modest. Which environment should the administrator provide to meet these requirements?
Unlock Premium Access
Salesforce Certified Platform Administrator II
- Access to ALL Certifications: Study for any certification on our platform with one subscription
- 2973 Superior-grade Salesforce Certified Platform Administrator II practice questions
- Unlimited practice tests across all certifications
- Detailed explanations for every question
- Admin II: 5 full exams plus all other certification exams
- 30-Day Money-Back Guarantee: Full refund within 30 days if unsatisfied
- Risk-Free: 7-day free trial with all premium features!
More Sandbox Types and Refresh Considerations questions
26 questions (total)