v6.5.3 is a focused quality release. Two things: Workflow Mapping now reads your project's real Azure DevOps state names and seeds the mapping accordingly, and the Configuration → License tab handles transient blips from the licensing service quietly instead of surfacing a raw error banner. If you're already running the extension, the most relevant section below is "What this means for your existing settings" — it spells out exactly what the upgrade will and will not touch.
What's new
- Workflow Mapping now reads your project's actual Azure DevOps state names — for example Agile process "Active", CMMI "Resolved", or Basic "Doing" / "To Do" — and seeds the mapping accordingly. Cycle Time, Flow Efficiency, and Monte Carlo render real data the first time you open them, instead of needing a manual mapping pass.
- The default fallback was extended. When state detection isn't possible (read-restricted projects, custom processes that don't return states), the built-in defaults now cover all four Microsoft ADO processes — Agile, Scrum, CMMI, and Basic — instead of only Scrum.
- Configuration → License is more resilient when the licensing service has a transient blip — no raw error banner. The page renders the last known state and retries quietly behind the scenes.
What this means for your existing settings
If you've been running the extension across 6.5.0 / 6.5.1 / 6.5.2, here's exactly what the upgrade will and will not change. Most customers will see nothing in their Configuration screen change at all.
- If you've edited Workflow Mapping at any point — added a state, removed one, changed work item types, or added a second project — your edits are preserved exactly. v6.5.3 will not touch them.
- If you've never opened the Workflow Mapping tab — or you opened it but didn't change anything — and your org is on the auto-saved default from 6.5.0 / 6.5.1 / 6.5.2: your single saved mapping will be refreshed once with the smarter version on first launch under 6.5.3. You'll see this happen silently; metrics that were blank or wrong start showing correct data.
- No other settings are touched by this release. Item Types, WIP rules, Sprint Alerts, Notifications, SLEs, Access Control, AI, Privacy, and License all stay exactly as you left them.
What to do if the new mapping isn't right for you
The smarter mapping is a starting point, not a verdict. If your team uses the states differently from the keyword matches we use, you can override per-project in two clicks.
- Open Configuration → Workflow Mapping and edit the mapping for your project. Once you save any change, your edited mapping is preserved across all future versions.
- Or click the "Contact us about this release" button in the in-product release notes — that opens our support form pre-filled with the release context so we can take a look together.
Behind the scenes
For the technically curious: auto-discovery now calls the Azure DevOps Work Item Types API to read your project's real states, then uses exact-or-prefix keyword matching to assign each state to a workflow bucket (e.g. "Active", "Doing", "In Progress" all map to Active; "Resolved", "Code Review", "Testing" map to Verifying). Empty buckets fall back to the extended defaults — so a custom process with no "Verifying" equivalent still gets a sensible default mapping rather than an empty bucket.
- The "stale auto-seed detector" only re-seeds mappings that byte-exactly match the v6.5.0–v6.5.2 default. Any customer customisation is honoured — even a single-character difference from the old default is treated as edited.
- No change to the data we collect or how we collect it. Workflow Mapping is computed entirely client-side from your existing Azure DevOps work item type definitions; nothing leaves your browser.
Update to v6.5.3 from the VS Marketplace. Existing trial and licensed orgs upgrade in place; no reactivation required.