Validation & QA

A device that has enrolled is not yet a device that works. This section is about proving each build before it reaches a user: per-device QA evidence, an initialled handover gate, and a BitLocker recovery key you have actually seen in the tenant.

Why this matters

There is a gap between enrolment finished and this person can do their job, and it is where provisioning projects lose their credibility. The Intune console will happily report a device as compliant, with required apps installed and the enrolment status page completed — and none of that tells you whether the finance package actually launches, the VPN authenticates, or the BitLocker recovery key genuinely reached the tenant. Most teams discover the difference through helpdesk tickets in the days after rollout: the build worked, but the handover failed.

Worse, when nobody records what was checked on which device, there is no evidence trail. When something breaks in month three, you cannot say whether it was ever verified at handover or drifted afterwards. A rollout without a QA gate makes every new device a small gamble taken by whoever receives it.

What a good build does

Treat handover as a gate with evidence, not a moment when the box changes hands. Decolla's catalogue closes each build with a per-build QA report covering the states that matter — required applications present, compliance evaluated, enrolment status page phases completed — paired with a per-device handover checklist that a named person initials. Line-of-business applications get deliberate treatment: configuration, permissions and first-launch sequencing are handled as their own step, because "installed" and "usable" are different states for LOB software. And BitLocker recovery-key capture, verification and escrow is a discrete step in its own right — the key is confirmed present in the tenant, not assumed from the fact a policy applied. The remaining checks in the section work the same way: each one exists to turn an assumption into a recorded fact before the device leaves IT's hands.

As with everything Decolla deploys, each item appears in the written, itemised plan — with its delivery method and reversibility class — before anything runs in your tenant. Honest scoping: this is structured verification at build time, with evidence written down per device. It is not continuous monitoring of the fleet afterwards, and we do not pretend otherwise.

Where it bites people

The BitLocker one first, because it is the expensive one. A device can show as encrypted in every console while the recovery key never reached Entra ID — encryption started before the escrow policy landed, or the key rotated and the backup silently failed. Nobody notices until a firmware update or TPM event throws the machine into recovery months later, and the portal has nothing for that volume. Handover is the one point where that failure is cheap to catch, which is exactly why it is a discrete, initialled step and not a footnote on the encryption policy.

Second: LOB first launch. An application can install cleanly and still fail the user at first run — an unactivated licence, an unset server address, an elevation prompt they cannot approve. Left unchecked, the person who discovers it is the user on their first morning with the new machine, which is precisely when the project's reputation gets set. Sequencing first launch during QA moves that discovery back to IT, where it belongs.

What's in this section (5 items)

Reversibility: auto reverses when unassigned · reverse reversible with a documented step · irreversible flagged before you approve the plan.