Microsoft · Windows update reporting

Update journey

Stage by stage, device by device.

I identified a gap in update reporting: a 94% success rate did not show where the other 6% stalled. I designed a flow visualization that drills from the fleet to a deployment ring to one device’s timeline. It started as a hackathon concept, shipped as a product feature, and was shown at Microsoft Ignite 2025.

The state point in time section of the update journey report. A date picker labeled select a date sits beside a Generate button, above a strip of stage counts — not started 1000, server stage 1500, client stage 3500, installed 1000, no telemetry 2000, not installed 500 and canceled 1000 — each marked with a colored rule. Below, a radio group headed view devices by stage they have reached offers server stage, client stage and process completed, with process completed selected. A flow diagram then carries devices left to right through four columns: not started, holding policy approved at 4000; server stage, splitting into scheduled at 3500 and on hold at 500; client stage, splitting into downloading or installing at 3500 and on hold at 500; and completed, ending in four color-coded bars — installed at 2000 in green, no signal at 500 in orange, not installed at 500 in red, and canceled at 1000 in gray, reached by a ribbon that leaves the first column directly.
Attrition becomes visible, and every branch opens the devices behind it.
Role
Lead designer — concept through shipped experience
Platform
Microsoft Intune admin center
Focus
Data visualization · Update reporting
Milestones
Ignite 2025 · GA 2026
Public reference
Microsoft announcement

The problem

Existing reports reduced updates to status counts: up to date, not up to date, or error. They hid where and why a device stalled.

An update is a pipeline: offer, download, install, restart, confirm. Each stage fails for a different reason and requires a different fix.

  • Statuses lacked detail. Devices that were never offered an update, failed to install, or failed to restart looked identical.
  • The denominator was unknown. Devices without a policy were omitted, so admins could not confirm the fleet’s true size.
  • Triage took days. Admins exported data, cross-referenced device lists, and decoded raw status codes.
  • Errors were cryptic. Specific causes appeared only as hexadecimal codes.

Telemetry was split across service status, client status, and final result, with no joined device journey. I mapped those boundaries with engineering; they defined the chart’s structure.

A redrawn state model in two panels. A row of three phase labels runs across the top: request received by service, upgrade in progress, and upgrade result. Below, a panel headed service side, UCServiceUpdateStatus, groups ten states — pending, holding validated and scheduled; offering, holding offer ready and offer received; on hold, holding admin paused, service paused and safeguard hold; and canceled, holding admin canceled, removed from deployment and service canceled. A gray arrow crosses a gap to a second panel headed client side, UCClientUpdateStatus, which groups eighteen more — installing, running download start, download complete, install start, install complete, restart required and restart complete; on hold, holding paused and safeguard hold; canceled, holding user canceled; uninstalling, holding uninstall, restart required, restart initiated, restart complete and rollback; and the terminal groups installed, uninstalled and unknown. A timeline showing when each state becomes knowable. A date axis is marked with three deployment milestones — groups A, B and C targeted, the expected start date, and the target completion date — and divided into four phases: policy created, request received by service, upgrade in progress, and upgrade result. Beneath each phase sit the states the telemetry can report there. Policy created gives total devices. Request received gives scheduled and offer ready, plus invalid devices. Upgrade in progress gives download start, downloaded and installing, plus no client telemetry, no Windows Update connection and no scan after deferral days. Upgrade result gives installed and not installed. The four states drawn with a dashed amber outline are keyed in a legend as arriving on a 24 to 36 hour lag, or not at all.

The two models I had to reconcile, redrawn from the published Windows Update for Business reports schema.

  • State model — 28 unjoined service and client states, including duplicate on-hold and canceled branches.
  • Availability map — states plotted by when they become knowable. Amber states arrive on a 24–36 hour lag, or not at all.

Jobs to be done

  • “Show me where this update actually is.” Not a percentage — a distribution across pipeline stages.
  • “Tell me where devices are falling out, and why.” Rank attrition by size and fixability.
  • “Let me compare this release to the last one.” Is this normal, or is this a problem?
  • “Take me to the devices so I can act.”
  • “Explain what happened to this machine.”

What I did

Chose a flow over another table.

I compared stacked bars, funnels, state tables, and flow diagrams. The flow preserved the denominator, made attrition visible, matched admins’ pipeline model, and scaled across fleet sizes.

A comparison grid titled Why sankey, scoring four chart types — stacked bar, funnel chart, state table, and flow or Sankey — against five criteria, with each cell marked pass, partial or fail. Preserves the denominator: fail, partial, pass, pass. Shows attrition as a shape: fail, partial, fail, pass. Matches the admin's mental model: fail, partial, fail, pass. Scales across fleet sizes: partial, partial, pass, pass. Familiar to most admins: pass, pass, pass, fail. The flow or Sankey column is outlined in blue, passing every criterion except familiarity.
Four candidates scored against the reporting needs.

I addressed the flow diagram’s known risks:

Risk How I handled it
Unfamiliar to many admins Put a plain-language summary above the chart
Screen readers cannot read it Provide an equivalent, navigable data-table view
Thin branches become unclickable Enforce minimum targets and group smaller branches under “Other”
Too many stages becomes spaghetti Show actionable stages by default and move substates down one level
Color alone cannot carry meaning Pair every color with an icon and label

Three properties of the chart became non-negotiable:

  • Constant total width. No device unaccounted for, including an explicit node for machines without a policy.
  • Comparison by default. Show whether a 6% failure rate is improving or worsening.
  • Every node is a doorway. Clicking any part of the flow produces a filtered, exportable device list.

The sortable, exportable table remained a peer view, not a fallback. It presents the same data in stage order for screen-reader users and admins who prefer tables.

Two panels side by side. On the left, headed data visualized, a small flow diagram with the note that it reads as a shape and is fastest for pattern recognition. On the right, outlined in blue and headed equivalent data table, a five-row table with columns for stage, devices, percent and change: offered 88,412 at 100%; downloaded 77,802 at 88%, change minus 12%; installed 68,961 at 78%, change minus 10%; restarted 61,888 at 70%, change minus 8%; up to date 61,888 at 70%. Beneath it, the table is described as fully navigable, sortable, exportable and announced in order.
In tests with 30+ IT admins, most preferred the visualization as the primary view.

Started the concept in a hackathon.

I turned the reporting gap I had identified into a self-initiated hackathon project. I tested three flow structures to make the idea tangible before scope and telemetry constraints narrowed the design.

A single continuous flow diagram covering every stage at once, drawn on a large working canvas. Total devices at ten thousand splits into scheduled at eight thousand, service on hold at one thousand and canceled at one thousand; the scheduled band then splits into download or install at five thousand, client on hold, no telemetry and device invalid at one thousand each; those resolve into installed at four thousand, no telemetry at one thousand and not installed at four thousand, the last carrying a red list of reasons. A flat fan-out. A single node, all devices at ten thousand, spreads in one hop to eight end states, banded on the right by the system that reports each one: deployment service holding scheduled and service on hold; client device holding download or install, client on hold and device invalid; and update result holding no telemetry, installed and not installed. Canceled at two thousand branches away low and separate. A four-column pipeline with saturated color at every stage — teal, pale blue, periwinkle, then green, orange and red. Policy created at ten thousand feeds scheduled, service on hold and canceled; those feed download or install, client on hold and device invalid; those end in installed marked with a green tick, no telemetry with an orange warning triangle and not installed with a red cross.

Three explorations:

  • Continuous flow — clear, but implied joins the telemetry could not support.
  • Fan-out by reporter — accurate to the data source, but lost sequence.
  • Staged pipeline — closest to the shipped structure; reserving color for the final column clarified outcomes.

The hackathon concept gained support and moved onto the product roadmap. Its core model survived: one visualization that narrows from fleet to ring to device while keeping the same stages, colors, and icons.

Three connected panels show the same update flow re-scoped from the full fleet, to one deployment ring, to one device. Each level keeps the same stage names, colors and visual structure while answering a narrower question.
One visual language across fleet, ring, and device.

Shipped it around the constraints.

With engineering and content design, I replaced error codes with three-part status messages: what happened, why, and what to do next. This was the most-cited improvement in user sessions.

Before and after panels. Before: a card reading “Update failed” above the code 0x800f0922 in red monospace, with a note that the admin must look this up externally, then work out what to do about it. After: three labeled sections. What happened — the update could not install because the system reserved partition is full. Why — third-party disk encryption is using space this update needs. What to do next — free space on the reserved partition, or apply the recommended remediation to 340 affected devices.
From error code to next action.

The MVP could not join service status, client status, and final result. I split the continuous concept into three stage views, each based only on available telemetry. I would make that trade again to ship, then prioritize joining the data.

The stage selector redraws the chart with fewer columns while keeping its anchor and stage names fixed. Each view answers a distinct question without looking like a different chart.

The stage selector set to server stage. A two-column flow: not started, holding policy approved at 1500, feeds server stage, which splits into scheduled at 1000 and on hold at 500. The server-stage bars are blue; the not-started bar is gray. The stage selector set to client stage. A three-column flow: not started, holding policy approved at 3500, feeds server stage, holding scheduled at 3500, which splits into three client-stage bars — downloading or installing at 2500, on hold at 500, and device invalid at 500. The client-stage bars are indigo; the earlier columns are gray. The stage selector set to process completed. A four-column flow: not started, holding policy approved at 4000, feeds server stage as scheduled at 3500 and on hold at 500, then client stage as downloading or installing at 3500 and on hold at 500, ending in completed — installed at 2000 in green, no signal at 500 in orange, not installed at 500 in red, and canceled at 1000 in gray, reached by a ribbon that leaves the first column directly.

One chart, three depths.

  • Server — whether the service handed out the update.
  • Client — where a device first fails rather than waits.
  • Completed — the full pipeline, with color reserved for outcomes.

The shipped flow narrows across four screens. Each selection opens the next level, ending with a device timeline plotted to real elapsed time.

The Summary tab for Windows quality updates. A multi-line trend chart plots number of devices over a thirty-day range, toggleable between percentage and device count. Beneath it, headline counts for up to date, in progress, not up to date, not ready and total device count. Below those, a table of policies — Marketing, VIP Devices, Finance, IT department, Windows Autopatch expanded to show its Test, First, Fast and Broad rings, and Test devices — each row carrying device count, up to date, in progress, not up to date, not ready, approved releases, and an update journey column whose cells are View links.
Step 1 · Fleet. Trends and policy groups, with a journey for every row.
The Quality update journey report, filtered to one target release and one policy, with OS version left at all. A status breakdown strip runs across the top with counts for request received by service, device upgrade in progress, update failed, update successful, no telemetry, canceled, and total devices. Below it, a state trending stacked area chart plots those states across six months, with a hover tooltip listing each state's device count and percentage. Below that, a state point in time section with per-stage counts, and a flow diagram carrying devices left to right through not started, server stage and client stage to completed, branching into installed, no telemetry, not installed and canceled, with intermediate service on hold and client on hold branches.
Step 2 · Journey. Trends show whether the rollout is moving; the flow shows where it stopped.
The Device status report for quality updates, filtered by two chips reading client state failed and policy Marketing. A strip of headline counts runs above the table — up to date, in progress, not up to date, paused, not ready and total device count. Beneath it a long device list carries columns for device name, update status, installed release, target release, target release available, Autopatch group, deployment ring policy, quality update policy, OS version, readiness, alerts, and an update timeline column of View links. Every row reads not up to date, the ring policy column names individual Autopatch and Finance rings, and readiness is a mix of ready and not ready.
Step 3 · Devices. Selecting a branch opens its filtered device list.
The update timeline for a single device. A device details panel lists device name, primary user, management name, ownership, compliance, serial number, operating system, device model, manufacturer and last check-in time. Beneath it, a horizontal timeline runs along a date axis from the tenth to the sixteenth of February, from a release marker to an installed marker, with event dots along it. Three open cards describe events: a warning that available storage dropped below 500 MB, a cleared temporary files event that freed 1.2 GB, and a download complete event. Below, a table lists each event with start time, end time and a status of completed, scheduled, in progress or warning.
Step 4 · Device timeline. The endpoint uses plain language and real elapsed time.

Outcome

What began as my hackathon initiative gained traction across the organization, became a shipped feature, and was presented at Microsoft Ignite 2025. Its reception validated both the problem I had identified and the unfamiliar visualization I proposed to solve it.

In March 2026, the quality update journey reached general availability as one of the four surfaces in the Windows Autopatch update readiness release — end-to-end, per-device visibility into where an update is and what is blocking it.

3

Drill-down levels — fleet, ring, and device — using one visual language.

100%

Fleet accounting, including devices without a policy.

  • Stalled-rollout triage dropped from days to one working session.
  • Admins could see their true coverage, including devices without a policy.
  • Plain-language status replaced error-code lookup.
  • Other platform teams reused the visualization pattern.
  • Microsoft MVPs and security practitioners singled out the initially unfamiliar chart type for praise.

Reception

The award for the best looking screen in Intune goes to this page.

Lewis Barry · Microsoft MVP, Principal Security Architect

It’s so hot, I love the sankey charts.

Kelvin Tegelaar · Microsoft MVP, founder of CIPP

What I’d do differently

I would test the table alongside the chart, not after it. In a data-dense product, it is a second primary interface, not an accommodation.