A Salesforce sandbox can be refreshed with a few clicks, but the timing decision is rarely simple. A team may have active development, open QA defects, integration credentials tied to the current org, and test data that took days to prepare. Replacing the environment without checking those dependencies can remove useful work. A Salesforce Sandbox Strategy gives each sandbox a clear job, sets the conditions that justify a refresh, and defines what has to happen before and after the copy.
Salesforce also sets different minimum refresh intervals by sandbox type. A Salesforce Developer Sandbox can refresh every 1 day, a Salesforce Partial Copy Sandbox every 5 days, and a Salesforce Full Copy Sandbox every 29 days. Those intervals are platform limits rather than recommended schedules. Refresh planning needs its own discipline rather than letting the Refresh link become the calendar.
TL;DR
A Salesforce Sandbox Strategy should start with environment purpose, release timing, data needs, and work protection. Developer sandboxes can be refreshed daily, but they should usually be reset when a feature cycle ends, production metadata drift affects new work, or the environment has become harder to clean than replace. Partial Copy can refresh every 5 days, yet QA and UAT should drive the timing because a refresh can remove carefully prepared test state. Full Copy can refresh every 29 days, so its window should be reserved for work that needs the closest production-like data and setup.
A Salesforce Sandbox Refresh also changes more than metadata and records. The sandbox receives a new org ID, some external connections can break, sensitive values in modern Named Credentials are not copied, and SSO may need work after activation. Protect what matters, refresh for a defined reason, and validate the environment before use.
Why Refresh Eligibility Is Not a Refresh Schedule
Salesforce publishes the minimum interval for each sandbox type. The official Salesforce sandbox refresh guidance also explains that the org ID changes each time a sandbox is refreshed. This means the first eligible date is only the earliest date Salesforce will accept another request. It says nothing about whether the current build, test cycle, or release calendar makes that request useful. A good Salesforce Sandbox Strategy adds business and release rules on top of the platform limit.
The environment’s job should decide the cadence. A development sandbox exists to isolate work. A shared integration environment checks whether merged changes behave together. QA needs a stable build and test dataset. UAT needs a controlled environment where business users can finish scenarios without the ground moving underneath them. Staging needs a production-like baseline for higher-risk validation. A refresh is useful when it helps that job. It is harmful when it wipes out the state the environment was created to support.
This distinction matters most with Full Copy because the wait between refreshes is long. If a team refreshes Full as soon as it becomes eligible, it may have no refresh available when a major regression cycle starts 2 weeks later. Eligibility should trigger a review, not an automatic action.
What Each Salesforce Sandbox Type Is Designed to Do
The sandbox type controls how much production data is copied, how much storage is available, and how soon another refresh can be requested. Salesforce’s current sandbox license and storage reference lists Developer at 200 MB of standard data storage, Developer Pro at 1 GB, Partial Copy at 5 GB, and Full at the same data storage as production. Developer and Developer Pro copy metadata only. Partial Copy adds sample data through a template, while Full can copy all production data. These differences should guide the environment map before a refresh policy is written.
| Sandbox Type | What Is Copied | Data Storage | Minimum Refresh Interval | Common Role |
| Developer | Metadata | 200 MB | 1 day | Isolated development and unit-level testing |
| Developer Pro | Metadata | 1 GB | 1 day | Development or shared testing that needs more data |
| Partial Copy | Metadata plus selected sample data | 5 GB | 5 days | QA, UAT, integration testing, and training |
| Full | Metadata plus production data | Same as production | 29 days | Staging, regression, performance, and load testing |
Developer Sandbox
A Salesforce Developer Sandbox is usually the best long-lived environment for isolated feature work. It copies production metadata but does not automatically bring across normal production business records. Developers can create, import, or seed the records needed for the feature. The 1-day interval makes reset easy after a feature cycle, but that speed can encourage unnecessary refreshes when a small deployment would solve the actual problem.
HyphenX’s Salesforce implementation services include Salesforce DX, version control, CI/CD pipelines, testing, and sandbox planning. Those controls keep approved work outside the org before reset. The refresh should return the developer to a clean source baseline without making the sandbox itself the source of truth.
Developer Pro Sandbox
Developer Pro follows the same metadata-only copy model but gives teams 1 GB of standard data storage. It can suit shared integration checks, larger feature datasets, or development that needs more records than Developer can hold. Its refresh interval is still 1 day, so the same trigger-based rule applies. Refresh when the next work cycle needs a cleaner baseline, and preserve required work before the existing environment is replaced.
Partial Copy Sandbox
A Salesforce Partial Copy Sandbox uses a template to select production objects and sample records. Salesforce can sample up to 10,000 records per selected object, subject to the 5 GB data limit. The current Partial Copy sampling guidance says relationships are enforced for Master-Detail and Required Lookup fields, while ordinary Lookup relationships are not guaranteed during sampling. Teams should verify the copied dataset and seed known scenarios when the random sample does not contain the relationships a test needs.
Partial Copy works well when testers need production-derived records without carrying the full production dataset into the environment. QA may need recent account structures, case records, products, opportunities, orders, or custom-object data. The sandbox template should be designed around those test cases. Copying more objects than testers need can add noise and increase the amount of sensitive data the team must control.
Full Copy Sandbox
A Salesforce Full Copy Sandbox can include production metadata and all production data, with storage matching production. Salesforce identifies Full as the only sandbox type intended for performance testing, load testing, and staging. It’s useful when data volume and production-like conditions matter to the test, such as a large migration rehearsal or a final staging exercise that needs relationships Partial Copy cannot guarantee.
What a Salesforce Sandbox Refresh Actually Replaces
A Salesforce Sandbox Refresh creates a new sandbox from the selected source. Once the refreshed copy is activated, the old sandbox is deleted. That replacement can remove sandbox-only metadata, test records, temporary settings, and development work that was never moved into source control. It can also reset a test environment that QA deliberately built into a certain state. The refresh process should therefore be treated like environment replacement rather than routine housekeeping.
The safest rule is that required metadata must have another home before the refresh starts. The pre-refresh steps below cover how to preserve it.
How to Set the Developer Sandbox Refresh Cycle
A Salesforce Developer Sandbox should be easy to replace once its work is safe. The daily interval gives teams flexibility, but a useful cadence is driven by development boundaries. One team may refresh at the start of each feature cycle. Another may refresh only when production metadata drift affects new work. A third may refresh after a developer hands off a completed feature and needs a clean environment for the next item. All 3 can be valid because the job of the sandbox is to support isolated development, not to stay on a fixed age.
A practical Developer refresh trigger list includes these conditions:
• Production metadata has changed enough to affect the next feature.
• A production hotfix changed a dependency that the developer now needs.
• The current feature is complete and its required work is safely stored.
• The sandbox contains old experiments that make new testing unreliable.
• A new release branch needs a clean production-based starting point.
• Required test records can be recreated without losing open defect evidence.
A Salesforce Sandbox Strategy should also define when a metadata deployment is better than refresh. If the sandbox only lacks a small approved production hotfix, back-promoting that change can be safer than replacing the whole org. Refresh is a larger action. Use it when returning to the source baseline is the goal rather than when the team simply needs 1 missing Flow or permission change.
Before refresh, developers should confirm that Apex, Lightning components, Flows, permission changes, and other required metadata are committed or otherwise preserved. These steps make the Salesforce Developer Sandbox disposable in the useful sense: the environment can be rebuilt without losing the history of the work.
How to Set the Partial Copy Refresh Cycle
The 5-day interval makes Partial Copy easier to refresh around QA and UAT than Full, but that does not mean every test environment should be replaced each week. A Salesforce Partial Copy Sandbox often contains carefully prepared records, users, integration states, and defect evidence. Replacing it can reset work that is more valuable than the newer production sample the team would receive.
A good Partial Copy trigger is the start of a new test phase that needs a newer production baseline. QA may need recent metadata because several production changes affect the release. UAT may need a current sample of accounts, cases, orders, opportunities, or custom objects. Integration testing may depend on reference data that has changed. When the current sandbox no longer supports the next test phase, a refresh makes sense.
The team should ask whether the problem is really the environment or only the dataset. If metadata is correct and QA only needs 20 known scenarios, targeted seeding may be better than replacing a Salesforce Partial Copy Sandbox. The current defect state stays intact while testers get the records they need.
The refresh decision should also consider the end of the test cycle. If business users are halfway through UAT, hold the environment stable unless a serious issue requires replacement. Refresh after the cycle closes, or preserve every record and reproduction step needed for open defects. Stability during testing matters more than keeping the sandbox as young as possible.
Partial Copy Test Data, Templates, and Masking
Refresh and test-data preparation should be treated as separate choices. A sandbox can have current metadata and still need better data. It can also have useful test data while its metadata needs a small back-promotion. Separating those needs prevents the team from using full environment replacement as a substitute for test-data management.
Use this checklist when planning a Salesforce Partial Copy Sandbox:
• Select only objects that support the current test scope.
• Review required relationships before relying on sampled records.
• Seed rare cases that random sampling may miss.
• Keep repeatable test records for business-critical flows.
• Apply masking where production-derived values are sensitive.
• Record which tests need Full because Partial Copy cannot represent the required volume or relationship pattern.
A Salesforce Sandbox Strategy should also state who owns the template. Sandbox templates can become stale when objects, relationships, and business processes change. Review them before major releases rather than assuming an older template still matches the current test scope. The owner should also confirm that newly added objects have a real testing purpose before expanding the data copied into the environment.
For Developer or Developer Pro, seeding can create smaller repeatable datasets. A known account hierarchy, order set, case history, or custom-object relationship can be recreated after refresh without waiting for random production sampling. Repeatable seed data is especially useful for automated tests because the team knows the expected starting state and can restore it after a reset.
Masking matters most when Partial or Full copies production-derived records. Customer contact details, personal identifiers, confidential notes, or financial values may not belong in a broad test environment. Access control, field masking, email settings, and external endpoints should all be reviewed before testers begin work. The safest dataset is the smallest one that still proves the required business behavior.
How to Set the Full Copy Refresh Cycle
A Salesforce Full Copy Sandbox should be scheduled from the release milestone backward. Start with the date for final regression, staging, performance testing, or migration rehearsal. Then allow enough time for the refresh to complete and for post-copy work to finish. Integration setup, credential restoration, masking, user checks, SSO repair, and smoke tests all happen before testers can rely on the environment. The request date is therefore earlier than the date the sandbox is actually needed.
The 29-day interval should influence release planning. Suppose a Full sandbox is refreshed for an early rehearsal and final UAT begins 20 days later. The environment cannot simply be refreshed again for a newer production dataset. The team must decide whether the same baseline is good enough, whether a Partial Copy can support one of the test stages, or whether the first Full refresh should move later. The answer belongs in the release plan before testing begins.
A Salesforce Full Copy Sandbox should be reserved for work that benefits from its fidelity:
• Final regression across high-risk business processes
• Production-scale integration testing
• Performance or load testing
• Major deployment rehearsal
• Complex data migration rehearsal
• UAT that depends on broad production-like records
Routine development rarely needs that environment. Using Full for ordinary feature work can tie up a scarce refresh window and expose far more production-derived data than the developer actually needs. A Developer or Developer Pro environment with controlled test data is usually easier to replace and easier to govern during active build work.
Refresh Cadence by Release Stage
A sandbox strategy works best when it is part of the delivery path. Small teams may have only a few environments, while large programs may have several development orgs and separate QA, UAT, and staging stages. The names matter less than the role. Each stage needs a stable source, a clear entry condition, and an exit condition that tells the next team when the build is ready.
No single calendar fits every Salesforce team. Release frequency, sandbox licenses, data sensitivity, integration count, and test depth all affect the cadence. The table below is a planning example rather than a Salesforce requirement. It shows how the refresh decision can be tied to work stages instead of sandbox age alone.
| Release Stage | Environment | Refresh Trigger | Pre-Refresh Check |
| Feature development | Developer | End of a feature cycle or material metadata drift | Commit work, preserve test setup, back-promote production fixes |
| Shared integration | Developer Pro or another shared sandbox | Start of a release train or heavy merge drift | Confirm branch state, package versions, and pipeline connection |
| QA | Partial Copy | Start of system test when newer data is required | Close or preserve open defects, review template, plan masking |
| UAT | Partial Copy or Full | Before UAT when the current dataset no longer fits | Confirm scenarios, users, and external test endpoints |
| Staging or performance | Full | Before major regression, migration rehearsal, or performance testing | Check 29-day window, masking, SSO, integrations, and setup time |
Integration-heavy releases need extra planning because each environment can point to different external systems. Salesforce API integration services cover API design, authentication, monitoring, and error handling across connected systems, which is the same boundary a refresh can disturb. A development sandbox may call a mock endpoint. QA may connect to a vendor test tenant. Full may use production-like volumes while still remaining isolated from live transactional services. Those rules should be documented by the environment.
The Salesforce Sandbox Strategy should sit beside the release calendar. Refresh dates, code freezes, UAT periods, production deployments, and Salesforce seasonal release windows affect each other. When the refresh plan is owned separately from the delivery plan, teams often discover conflicts too late. Release owners should be able to see the next eligible refresh date and the next planned use of each shared environment in the same planning process.
A Salesforce Sandbox Refresh can therefore be weekly in one environment and release-based in another. The cadence is correct when it supports the next stage without destroying useful work from the current one. Teams with more licenses can stagger environments so one remains stable while another is prepared. Teams with fewer licenses need stricter scheduling because each sandbox may support several roles across a release. Review the Salesforce Sandbox Strategy when release frequency changes so the cadence still matches the delivery model.
When You Should Not Refresh a Sandbox
The best refresh decision is sometimes to keep the current environment. A refresh solves drift and data-age problems, but it can remove a useful test state or break connections that are working. The team needs explicit stop conditions so the Refresh link does not become the default answer to every environment issue.
Delay the refresh when any of these conditions apply:
• Required changes still exist only in the target sandbox.
• QA or UAT is in progress and the current state is still needed.
• Open defects depend on records that would be removed.
• A production deployment is underway and the release baseline is still changing.
• Integration owners have not captured endpoints and credential requirements.
• A Full refresh now would block a more important refresh inside the next 29 days.
• The team only needs a small approved metadata change.
• Test data can be reseeded without replacing the org.
These stop conditions should be part of the runbook, and a postponed refresh should get a new decision point so it does not disappear from the release plan.
What to Do Before Every Refresh
Pre-refresh work should scale with the environment. A personal Developer sandbox may need a short checklist. Shared QA and Full environments need a formal gate because more people and systems depend on them. The goal is to make every required piece of work recoverable before the old sandbox is replaced.
Protect Metadata and Release Work
Compare the target environment with the agreed source of truth when drift is uncertain. Confirm that required developer and admin changes are committed, packaged, exported, or documented through the team’s normal delivery process. Do not focus only on Apex. Flows, permission sets, validation rules, Lightning pages, reports, and configuration changes can all disappear if they exist only in the sandbox.
Preserve Required Test Evidence
QA should identify records that reproduce open defects and preserve the values needed to rebuild them. Integration teams should save sample payloads and expected results. Business testers should record where they stopped in long-running scenarios. If the environment contains data that took hours to construct, decide whether it should be exported or recreated through a repeatable seed process.
Freeze the Target Environment
Stop new changes before the refresh request. Pause deployments that target the sandbox. Tell developers, admins, testers, and release owners when the environment will be unavailable. A named owner should decide when the pre-refresh gate has passed and when the environment can be released back to users.
Record Environment-Specific Settings
Document non-production endpoints, SSO details, integration users, email settings, scheduled jobs, connected tools, and any other values that differ from the source org. Some settings will copy and need to be changed. Some sensitive values will not copy and need to be restored. The runbook should tell the team which case applies and who owns the repair after activation.
What Changes After a Refresh
Salesforce can report that a sandbox copy is complete while the environment is still not ready for development or testing. The post-refresh phase should restore environment-specific controls and verify that the new org behaves as expected. The team should treat “copy complete” and “ready for use” as separate states.
A post-refresh readiness check should cover:
• User access and permission assignments
• SSO and direct admin login
• Named Credentials and External Credentials
• Connected Apps and OAuth sessions
• Integration endpoints and middleware
• Email deliverability and test addresses
• Scheduled Apex, batches, and automated jobs
• DevOps or CI/CD environment connections
• Data masking and test-data seeding
• Automated tests and business smoke tests
The checklist should end with a named owner declaring the environment ready and keeping affected users out until any failed checks are fixed.
Why Named Credentials Need Attention
Modern Named Credentials protect secrets from being copied into a new sandbox. Salesforce’s Named Credentials guidance says sensitive values such as access tokens, API keys, and passwords are not copied from production when a sandbox is created, refreshed, or cloned. The parameter definitions can still be present, but the non-production environment must be authenticated again. This is a deliberate safety control, and it creates required work after refresh.
The integration owner should restore only credentials meant for the sandbox. It should also verify that each Named Credential points to the correct non-production endpoint. Copying production configuration into a sandbox can create risk when a URL still points to a live service. A missing secret is easy to notice because the call fails. A copied live endpoint may be harder to notice if the call succeeds.
Why SSO and Org Identity Can Break After Refresh
Every sandbox refresh creates a new org ID. That change can affect tools and identity settings that depend on the previous org. Salesforce’s current SSO sandbox refresh guidance says SAML settings are copied from production, but the Recipient URL changes to the refreshed sandbox URL and the SAML configuration is disabled. The identity provider may need updated metadata before normal SSO access returns.
Teams that rely on SSO should keep a controlled direct-admin login path for refresh work. An administrator must be able to enter the sandbox while the identity-provider connection is being repaired. The team should test the exact user groups that depend on SSO because profile and permission settings can affect how people regain access. Access testing should happen before a large UAT group is invited back into the environment.
Org ID changes also affect external tools. Salesforce’s DevOps Center refresh guidance states that the connection to the original sandbox is lost after refresh because the new sandbox has a different org ID. The environment must be swapped or reconnected before normal pipeline activity resumes. A sandbox name can remain familiar while the connected systems see a new org underneath it.
How to Validate Integrations After Refresh
Integration validation should happen before QA or UAT begins. The first business user should not be the person who discovers that an external API is still pointed at production or that authentication was never restored. The team should know which connections are safe to enable in each environment and which should stay disabled.
Use a controlled sequence:
1. Confirm that each sandbox connection points to an approved non-production endpoint.
2. Restore credentials through the approved secret process.
3. Test authentication without sending a live business transaction.
4. Run one controlled outbound request and confirm the expected response.
5. Test an inbound flow where the external system provides a test environment.
6. Review error handling, retry behavior, and record updates.
7. Enable scheduled jobs only after the connection passes those checks.
Some production systems have no safe test tenant. In that case, the sandbox should use a stub, mock service, disabled job, or other approved substitute. A successful Salesforce Sandbox Refresh does not justify reconnecting every copied integration automatically. The goal is to restore only the paths the test environment is designed to use while keeping production systems outside the test boundary.
How Salesforce Release Preview Affects Refresh Timing
Salesforce major releases create another timing decision. Preview sandboxes move to the upcoming Salesforce release before production, while non-preview environments remain aligned with the current production release until the production upgrade. The platform publishes cutoff instructions for each seasonal release. A refresh near that boundary can change which release the sandbox receives.
The current Salesforce sandbox preview instructions explain how refresh timing affects Preview status. A team should decide which environments need early release testing and which environments must stay aligned with production for final UAT or staging. The answer may differ across the same Salesforce program, which is why the preview decision belongs in the Salesforce Sandbox Strategy rather than being left to the admin who happens to request the refresh.
A Salesforce Full Copy Sandbox used for final staging often needs close alignment with production. Another sandbox may deliberately move to Preview so developers and QA can test custom code, managed packages, and integrations against the coming platform release. Planning both paths avoids a late choice between early release validation and current-production alignment.
How to Prevent Sandbox Drift Between Refreshes
Refreshes cannot solve every drift problem. Production hotfixes, emergency admin changes, package upgrades, and parallel features can create differences days after a refresh. If every difference leads to another replacement, developers lose time and QA loses stable test state. A better approach uses source control and controlled back-promotion to keep important changes moving through the environment path.
Production hotfixes should return to the development path after they are released. Production fixes and approved admin changes should be reflected in the source used by future work so the same drift does not keep returning.
Managed packages can create another form of drift, since teams may need to track package versions across multiple environments. A refresh may copy one version from the source while the target test stage needs another. Package state should therefore be part of the environment record rather than an assumption.
The long-term aim is to make sandboxes rebuildable. Source control should preserve development history. Test-data scripts should preserve important scenarios. Runbooks should preserve an environment-specific setup. The sandbox itself can then be replaced when there is a valid reason without becoming the only place where the team knows how the system works.
How to Choose the Right Refresh Cadence
The team can choose a cadence through a simple decision path. Start with purpose and work protection before looking at the eligible date. This keeps the refresh tied to the release rather than to a timer.
1. Name the environment’s job: development, integration, QA, UAT, staging, or performance work.
2. Measure relevant drift: check whether back-promotion can handle it instead.
3. Check active work: find metadata, test records, and open defects a refresh would remove.
4. Check data needs: decide whether targeted seeding can supply the scenarios.
5. Check the platform interval: confirm the 1-day, 5-day, or 29-day minimum has passed.
6. Check the release calendar: protect later QA, UAT, staging, Preview, and production windows.
7. Plan post-refresh work: assign owners for credentials, SSO, integrations, pipelines, and smoke tests.
Conclusion
A Salesforce Sandbox Strategy is useful when it turns refresh timing into a release decision. Developer and Developer Pro can refresh every 1 day, Partial Copy every 5 days, and Full every 29 days. Those numbers define the earliest possible refresh. They do not define the safest or most useful date for the team. When these steps are part of the release calendar, refreshes become predictable environment changes rather than interruptions that catch developers and testers by surprise.
FAQs
How Often Should a Salesforce Developer Sandbox Be Refreshed?
A Salesforce Developer Sandbox is eligible for refresh every 1 day. Use that interval as flexibility rather than a daily schedule. Refresh when production metadata drift affects new work, a feature cycle has ended, or the environment needs a clean baseline. Preserve active changes and required test data before replacement so the reset does not remove work that still belongs in the release.
How Often Can a Partial Copy Sandbox Be Refreshed?
A Salesforce Partial Copy Sandbox can refresh every 5 days. The useful cadence usually follows QA, integration testing, or UAT milestones. Keep it stable while a test cycle is active. If testers only need new records, seed the needed data instead of replacing the whole environment and removing the state used by current defect testing.
How Often Can a Full Sandbox Be Refreshed?
A Salesforce Full Copy Sandbox can refresh every 29 days. Plan the request backward from staging, regression, performance testing, or migration rehearsal. Leave time after the copy for masking, SSO repair, credentials, integration checks, and smoke tests. The environment should be ready before the test begins rather than refreshed on the day testers need it.
Does a Sandbox Refresh Delete Existing Work?
After the refreshed copy is activated, the old sandbox is deleted. Work that exists only there can be lost. Preserve required metadata in source control or through the normal release process, and record any test state that must be recreated before the refresh starts. Shared environments need this check because several teams can hold work in the same sandbox.
Is Partial Copy the Same as a Smaller Full Sandbox?
No. Partial Copy uses a template and sampled production data. Salesforce can copy up to 10,000 records per selected object within the data limit, but ordinary Lookup relationships are not guaranteed during sampling. Verify the dataset and seed known scenarios that the sample misses before relying on the environment for important business testing.
Should UAT Use Partial Copy or Full?
Both can support UAT. Partial Copy often works when selected production-derived records are enough. Full fits higher-risk testing that needs broader data relationships, production volume, or staging-like conditions. The test design and release risk should decide which environment is used rather than a fixed policy that sends every UAT cycle into Full.
Why Can SSO Stop Working After a Sandbox Refresh?
A refreshed sandbox gets a new org ID, and its SAML Recipient URL changes. Salesforce disables the copied SAML configuration after refresh, so the identity provider may need updated sandbox metadata before normal SSO access returns. Keep a controlled direct-admin login route available so the team can repair the connection without depending on the broken SSO path.
