Is tomorrow's Dynamics 365 deployment safe?

Examples come from the Flow Trace demo estate, RautingTech's own test environment. No client data or client work is described.

Every pipeline has this moment. The deployment is scheduled, the checklist is mostly checked, and the last thing standing between now and "go" is a solution comparison across three environments that don't quite agree with each other. Dev is on Field Ops 1.2.0.0. QA is on 1.1.0.0. Prod is still on 1.0.0.0. Nothing about that sentence, by itself, tells you whether tomorrow is safe.

That's the trap in the naive version of this check: version skew is not the finding. A dev/QA/prod pipeline is supposed to have version skew — dev is always a little ahead, because that's where the next release is being built. The real question isn't "are the versions different." It's "which of these differences are just work waiting its turn, and which ones are actual problems that will bite tomorrow."

Work in progress isn't the alarm

Look closer at what's different and a pattern falls out. There's a Customer Portal solution — unmanaged, version 0.3.0.0 — that exists only in dev. Nobody promoted it because it isn't finished. That's not drift. That's a feature in progress, sitting exactly where unfinished work is supposed to sit, and treating it as an incident every time the comparison runs is how administrators learn to stop trusting the comparison.

This is why environment role matters as much as the diff itself. Tag an environment as dev, and anything unmanaged and unpromoted there gets read as work in progress instead of a red flag. Tag the same kind of gap downstream — in QA or prod — and the read flips, because nothing is supposed to originate there. The distinction isn't cosmetic. It's the difference between a comparison you check once and ignore, and one you actually trust enough to check every week.

What real drift looks like

Now the flow list. In dev and QA, the flow that turns a completed work order into an invoice is Started. In prod, it's Stopped. Nobody wrote that down anywhere. That's not unreleased work sitting in dev waiting its turn — it's a live production process that someone silently disabled, and every work order completed in prod since then has generated no invoice and told nobody. This is the exact class of incident environment comparison exists to catch: works in dev, silently off in prod, discovered by a customer instead of by the person who could have fixed it in five minutes.

There's a second kind of drift running the other direction. A Legacy Reports solution exists in QA and prod — but not in dev. That's backwards. Solutions are supposed to start upstream and move downstream, not the other way around. A solution that's present only downstream means it was built or imported directly against a live environment, never captured anywhere it could be reviewed first. It doesn't need a version number to be worth a flag; the fact that it has no upstream origin is the flag.

The hotfix nobody wrote down

Then the one that actually changes the decision. Sitting in prod, unmanaged, is a solution nobody in dev has ever heard of — a prod-only hotfix, version 1.0.0.1. And in the unmanaged-layer inventory — which scans the hidden Active solution in every environment on every ingest cycle, because that's where undocumented changes actually live — there's a web resource patch applied directly on top of the managed work-order form, in prod, and quietly in QA too. Nobody planned that patch through the pipeline. It exists because someone needed a fix fast, made it directly against a live environment, and moved on. A healthy prod environment should show zero unmanaged layers. This one doesn't.

That single finding changes what "safe" means for tomorrow. If the plan is to promote dev's version of Field Ops as-is, it lands directly on top of a change nobody currently on the deployment call knows exists. Nobody can say what the interaction will be, because until this afternoon nobody knew there was anything to interact with. That's not a reason to cancel the deployment. It's a reason to know about the hotfix before it happens instead of after.

The connection reference nobody bound

One more thing turns up on the way to "go": the Office 365 connection reference is bound in dev and in QA, and unbound in prod. Nobody set a connection after the last production import — an unbound reference fails every dependent flow at activation, which is the classic day-after-import breakage, and it's sitting there right now, waiting for the next flow that gets reactivated to walk straight into it. If tomorrow's deployment touches that flow at all, it breaks the moment it goes live — not because of anything new, but because of a gap that's been open since the last release and nobody closed.

The pre-flight, before any of that

Underneath the manual review sits a narrower, sharper question: can this solution actually import into the target at all. A deployability check answers that before the deployment is attempted, rather than after the pipeline rejects it — checking whether the solution references a component the target doesn't have, or whether two solutions require each other in a cycle that makes no import order work. That's not a judgment call the way work-in-progress versus drift is; it's closer to a fact. Either the dependency exists in the target or it doesn't.

The call

None of this is a reason to cancel Saturday's window. It's a reason to make three decisions instead of one blind one: bind the connection reference in prod before the deployment starts, since that's a five-minute fix either way; write down the prod hotfix as a decision the team is making with eyes open, instead of a landmine discovered by whoever imports next; and leave Customer Portal exactly where it is, because it was never supposed to be part of tomorrow's release in the first place.

What changes after a Thursday like this isn't the deployment process — it's when the questions get asked. Instead of a version-number gut check the night before a release, the comparison becomes a standing weekly habit, and drift gets caught days before a change window instead of hours before it, when there's still time to do something other than hope.

See it yourself

Connect two or more environments and the comparison runs against your own pipeline: version skew, disabled flows, unbound connection references and hand edits over managed solutions, in one view, with a plain verdict per solution. Run it before your next deployment window, not after it.

Request early access or book an estate review.