Org Drift: Why Your Salesforce Sandboxes Stopped Matching Production

Short answer: org drift is the accumulated cost of every change that reached an org without going through your process. It is not caused by one bad admin or one skipped review, it is the sum of hundreds of small legitimate exceptions. And the quarterly sandbox refresh most teams rely on cannot fix it, because refreshes happen on a monthly-at-best cadence while drift is created daily.

What is org drift?

Org drift is the divergence between what an environment contains and what your source of truth says it should contain. Between sandbox and production, between two sandboxes, or between production and the repository that is supposed to describe it.

The symptom everyone recognises: a change that passed every test in a sandbox fails on the way into production. The cause is almost never the change. It is that the sandbox stopped being a fair test.

Where does drift actually come from?

Nearly all of it comes from changes that were reasonable at the time:

• Configuration made directly in production. A picklist value added on a Friday because a deal needed it. Correct decision, invisible to your repo.
• Hotfixes that never got back-merged. The fix shipped. The branch it should have landed on did not get it.
• Packages installed in one environment. Someone installs an app in a sandbox to evaluate it, or in production to unblock a team.
• Permissions granted by exception. Profile and permission set edits are the fastest-drifting metadata in most orgs and the least likely to be in version control.
• Environment-specific settings that were never meant to match. Endpoints, named credentials, email deliverability, scheduled jobs. This is legitimate drift, and it still has to be declared, because if you cannot tell legitimate drift from accidental drift you will end up ignoring both.
• Salesforce's own release schedule. Instances upgrade at different times, so two environments can genuinely be on different versions of the platform for a window.

None of that is negligence. It is a system that lets change enter through more than one door.

Why does the quarterly refresh not fix it?

The refresh ritual assumes drift can be reset periodically. Look at the cadence Salesforce actually allows: Developer and Developer Pro sandboxes can be refreshed roughly once a day, Partial Copy every five days, and Full sandboxes every 29 days (see Salesforce's sandbox types documentation).

So the environment that matters most for realistic testing, the Full sandbox, has a hard floor of roughly a month. In practice nobody refreshes at the maximum rate anyway, because a refresh wipes in-flight work, needs data masking and re-seeding, and costs a team days of setup afterwards. Quarterly is the honest number.

Meanwhile drift is created every single day. You cannot fix a daily problem with a quarterly ritual. The refresh is not useless, it just resets a counter that immediately starts climbing again, and between refreshes your confidence in your test environment decays continuously while nobody measures it.

What does drift actually cost?

• Failed deployments. The visible cost, and the smallest one.
• False confidence. Far worse. Tests that pass against a drifted sandbox tell you nothing, and you do not find out until production.
• Longer estimates. Teams add buffer for deployment surprises. That buffer is drift, priced in.
• Rollbacks that do not fully roll back. If production contains config your repo never had, reverting to the repo is not a return to a known state.
• Audit exposure. "What is in production and who put it there" should have one answer.

What does continuous drift detection look like?

1. Declare a source of truth. Usually Git. Everything else is compared against it. Without this step, drift detection just produces two lists and no verdict.
2. Snapshot every environment on a schedule. Daily beats weekly. The value is in catching a change while the person who made it still remembers why.
3. Classify the diff, do not just display it. Three buckets: expected environment differences, accepted exceptions with an owner and an expiry, and genuine unplanned drift.
4. Route it to a human immediately. A drift report nobody is accountable for is a dashboard, not a control.
5. Close the loop back into the repo. Legitimate production changes should be captured into source, not just flagged. Otherwise every detection cycle reports the same item forever.

Most tools in this category can compare two environments. The differences that matter are whether the comparison runs on a schedule without anyone remembering to start it, whether the output is classified rather than raw, and whether it is wired to the same pipeline that deploys.

That is the design point in Serpent: drift detection sits next to delta deployments, one-click rollback and AI code review that flags governance drift on every change, and it runs through standard APIs with nothing installed in your org. Detection and deployment in one place means the fix is one action rather than a ticket to a different team.

What should you do this week?

Pick your most business-critical sandbox and diff it against production once. Sort the results into "expected", "we knew about this" and "who did this". If the third bucket is the biggest, stop scheduling refreshes and start scheduling comparisons.

FAQ

What causes Salesforce org drift?

Changes that reach an org outside the deployment process: direct production config, un-merged hotfixes, packages installed in one environment, permission edits, and legitimate environment-specific settings that were never documented as such.

Does refreshing a sandbox fix drift?

Only momentarily. Full sandboxes can be refreshed every 29 days at best, and most teams manage quarterly, while drift accumulates daily.

How often should you check for drift?

Daily for production and any environment used for release validation. Anything slower and you lose the context needed to explain what changed.

Is all drift bad?

No. Endpoints, credentials and scheduled jobs are supposed to differ. The problem is not that differences exist, it is that undeclared differences are indistinguishable from mistakes.