A salesforce sandbox refresh doesn't just reset your data. It rebuilds the org from a production snapshot, which means every unpackaged config change, every connected app, every named credential and outbound message you set up since the last refresh gets erased. Teams treat refreshes as routine maintenance. They aren't. They're a full org replacement event that can quietly break your entire deployment pipeline if nobody plans for it.
The damage rarely shows up on refresh day. It shows up two weeks later when a scheduled job stops firing, an integration user gets an authentication error, or a CI pipeline can't authenticate against the sandbox anymore. By then nobody remembers the refresh happened, so the debugging starts from zero.
What Actually Survives a Sandbox Refresh
A refresh pulls a copy of production metadata and data into the sandbox, overwriting whatever was there. That means anything you built directly in the sandbox and never deployed back to a source of truth is gone. Anything that lives in production and gets copied down survives, at least until the next production change diverges from it.
Here's the split that actually matters for a deployment pipeline:
| Survives refresh (copied from production) | Wiped on refresh |
|---|---|
| Deployed metadata (objects, fields, flows already in prod) | Sandbox-only config never pushed to prod |
| Production data (if full or partial copy sandbox) | Test data seeded manually post-refresh |
| Users and profiles matching production | Sandbox-specific user records and permission tweaks |
| Standard org-wide settings | Connected apps, named credentials, remote site settings created in sandbox |
| Managed package installs (usually) | OAuth tokens, API keys, scheduled jobs, outbound messages |
Notice the pattern. Anything that lives in production metadata comes back fine. Anything that exists only as sandbox-specific configuration, which is exactly what CI/CD tooling depends on, gets deleted without warning.
The Integration and Auth Layer Takes the Hardest Hit
Connected apps are the most common casualty. If your deployment tool authenticates to the sandbox through a connected app you configured after the last refresh, that connected app is gone. Named credentials pointing to external systems, deleted. Remote site settings that whitelisted your CI runner's IP range, deleted. OAuth tokens your pipeline cached for unattended deploys, invalidated.
This is why teams report deployment failures right after a refresh that look nothing like a metadata problem. The error says authentication failed or endpoint not reachable, and someone spends an hour checking package.xml when the real issue is a wiped remote site setting. I've seen a four-person admin team lose an entire afternoon to this exact scenario because nobody connected the dots between Monday's sandbox refresh and Wednesday's failed pipeline run.
Scheduled Apex jobs and paused flow interviews get reset too. If your pipeline depends on a scheduled job kicking off validation or cleanup after deploy, check that it's still scheduled post-refresh. It usually isn't.
Data Divergence Breaks Validation-Only Deploys
A validation-only deploy runs your test classes against the target org's data and config. After a refresh, that data now matches production exactly, which sounds good until you realize your test classes were tuned around sandbox-specific record volumes or edge cases that no longer exist.
Full and partial copy sandboxes are worse offenders here than developer or developer pro sandboxes, simply because they carry more production data forward. A validation rule that never triggered against your old sandbox data might suddenly fire against the fresh production copy, failing a deploy that worked fine last week. The metadata didn't change. The data underneath it did.
Partial copy sandboxes add another wrinkle: the sampling logic that decides which records come over isn't always consistent between refreshes, so your test coverage against edge-case records can shift without any code change on your end.
Building a Refresh Runbook That Doesn't Wreck the Pipeline
Most of this pain is avoidable with a checklist run every time a refresh happens, not just the first time. Treat it like a deployment step, not an afterthought.
- Document every connected app, named credential, and remote site setting created directly in the sandbox, and keep that list current between refreshes.
- Re-authenticate your CI/CD tool and any deployment automation immediately after refresh, before anyone assumes the pipeline still works.
- Re-schedule Apex jobs and re-activate paused flow interviews that support your release process.
- Re-run your full test suite against the refreshed org before trusting a validation-only deploy result.
- Notify the whole delivery team when a refresh is scheduled, not just the admin who requested it.
That last point sounds obvious and gets skipped constantly. A refresh requested by one team for UAT purposes can silently break a release another team was about to validate. Put refresh dates on the same calendar as your deployment freeze windows.
Where Deployment Automation Actually Helps
This is where a tool like DeployEzee earns its keep instead of just being another dashboard. Because it resolves metadata dependencies and maps what's actually present in target orgs before a deploy runs, it surfaces missing connected apps, absent remote site settings, and broken references as pre-deploy warnings rather than mid-deploy failures. You find out what the refresh took away before you burn a deployment window discovering it the hard way.
One-click deployment doesn't remove the need for a refresh runbook, but it does remove the guesswork about what state the sandbox is actually in right now. Instead of manually re-checking every connected app after a refresh, the dependency scan flags what's missing against what your deployment package expects. That turns a reactive scramble into a five-minute pre-flight check.
The comparison view between sandbox and production metadata also catches the data-divergence problem from the validation section above. If a validation rule behaves differently after refresh, you can see exactly which metadata differs between environments instead of guessing which field or rule changed underneath you.
Timing Refreshes Around Your Release Calendar
Full and partial copy sandboxes can only be refreshed on fixed intervals, so plan releases around that constraint rather than fighting it. Schedule refreshes right after a major release closes out, giving the team a clean window to rebuild sandbox-specific config before the next sprint's deploys start stacking up.
Never refresh mid-release. If your team is three deploys into a feature branch cycle, a refresh wipes the sandbox-only integration testing state you've built up, and you'll rebuild it under deadline pressure instead of on your own schedule. Treat the refresh calendar with the same rigor you'd apply to a deployment freeze window, because functionally it's the same kind of risk.
Developer and developer pro sandboxes are cheaper to refresh and easier to recover, so use them for anything that needs frequent resets, and reserve full/partial copy refreshes for milestone checkpoints. That single decision cuts most of the accidental-breakage stories teams tell about refresh day.
Frequently Asked Questions
Does a sandbox refresh delete Apex code and Lightning components?
No, if that code and those components already exist in production, they come back through the refresh copy. The risk is metadata that exists only in the sandbox and was never deployed to production, which gets overwritten and lost.
Why does my deployment pipeline fail right after a sandbox refresh?
The most common cause is a wiped connected app, named credential, or remote site setting that your CI tool depended on for authentication. These are sandbox-specific configurations that don't survive a refresh unless they also exist in production.
How often should full copy sandboxes be refreshed for a deployment pipeline?
Salesforce limits full copy refreshes to once every 29 days, so most teams align that refresh with the close of a major release rather than mid-sprint. Refreshing right after a release gives the team time to rebuild sandbox-specific config before the next deploy cycle picks up.
Do scheduled Apex jobs survive a sandbox refresh?
Scheduled jobs and paused flow interviews are typically reset during a refresh and need to be manually re-scheduled or reactivated afterward. This is a frequent cause of silent automation failures that show up days after the refresh itself.
Can deployment automation detect what a sandbox refresh removed?
Tools that scan metadata dependencies before a deploy, like DeployEzee, can flag missing connected apps, absent remote site settings, or broken references as pre-deploy warnings. That surfaces refresh-related gaps before they cause a failed deployment instead of after.