Mapping source statuses onto board statuses

Every synced item arrives with a source-side status — a Jira status, an ADO state, a GitHub label or open/closed state — and the mapping editor decides which of your board's own statuses that becomes. Leave a value unmapped and nothing gets dropped; the sync falls back to a sensible default instead.

deckgauge · Jira status mapping
Jira status mapping 4 mapped of 5 known
Jira statusBoard status
To DoNot Started
In ReviewIn Progress
Blocked (Vendor)— unmapped —

Each row is a real value pulled from synced data, not a guess.

What it does, and where the data comes from

The choices on the left side of the editor aren't a fixed enum — they're the distinct values your synced data actually contains, queried live per provider:

ProviderSource field queriedNotes
Jiradistinct status on synced issues for the projectWhatever status names your workflow actually uses
Azure DevOpsdistinct state on synced work items for the projectCustom process templates show their own state names
GitHubdistinct issue labels, plus the synthetic open and closedGitHub has no status field — labels and open/closed state are all there is

Values already in your saved mapping stay listed even if they haven't appeared in a recent sync, so editing an old mapping never silently loses a row.

How to edit a mapping

  1. Open a board's Source zone for the connection and choose Status mapping.
  2. For each source value, pick a board status from the dropdown, or leave it as — unmapped —.
  3. Save changes persists the mapping; Clear all mappings resets every row back to unmapped in one click.

Under the hood

Matching is case-insensitive for all three providers — "In Progress" in your mapping matches a source value of "in progress" or "IN PROGRESS" equally. This matters most for GitHub, where the promotion path checks an issue's labels against the mapping first, then its open/closed state, all case-insensitively, before falling any further.

All three providers ship with a sensible default mapping already filled in when a sync is first created (Jira: To Do/Open/Backlog → Not Started, In Progress/In Review → In Progress, Done/Closed/Resolved → Done, and so on; GitHub: open → In Progress, closed → Done). You're editing on top of that default, not starting from a blank slate.

What "unmapped" actually doesAn unmapped value is never dropped from the board. The resolution order is the same shape across Jira, GitHub, and Azure DevOps: (1) check the mapping, case-insensitively; (2) fall back to a case-insensitive name match against an existing board status; (3) if nothing matches at all, create a new board status named after the source value verbatim. In practice this means a truly novel status shows up as its own new board status the first time it's seen, rather than silently disappearing.

If it looks wrong

SymptomCauseFix
A GitHub issue lands in an unexpected board statusOne of its labels matched the mapping before its open/closed state was checkedRemember labels are checked first — remove or remap the conflicting label
A brand-new board status keeps appearingA source value with no mapping and no case-insensitive name match on the boardMap it explicitly, or rename the auto-created board status and map future occurrences to it
A status you know exists isn't in the pickerNo synced item has carried that value yetWait for a sync to observe it, or add the mapping manually once it appears

Related

Last updated