A board for types that never reach a backlog

Support requests, customer feedback, impediments, risks and test cases are real work with real states, and none of them appear on any backlog. Azure Boards draws a board for the backlog levels of a team, so a work item type that sits outside that hierarchy has no board at all. The items exist, people work on them every day, and the only way to see them together is a query result: a flat table, with no columns, no flow and no order anyone agreed on.

AnyKanban closes that gap without changing anything about your process. A query finds the items, the work item type's own state model supplies the columns, and everything the query returns becomes a card.

This guide is written for the process owner or team lead who runs this kind of work. It covers the query, the board, telling several types apart, making service-level pressure visible, and, the part that decides whether the board is trusted, what happens when the types you put on one board have state models that do not line up.

The types this guide is about

The demo organization runs the same five types most insurers and banks end up with beside their delivery backlog:

Each one already has states, an owner and a life cycle. What none of them has is a column.

The query

Board membership comes from one saved flat query. For the support desk in the demo organization, with the neighboring types it works alongside:

SELECT [System.Id]
  FROM WorkItems
 WHERE [System.TeamProject] = 'Claims Platform'
   AND [System.WorkItemType] IN ('Support Request', 'Feedback', 'Impediment', 'Test Case')
 ORDER BY [Microsoft.VSTS.Common.StackRank] ASC

Three details separate a board that works from one that half-works:

• Flat list of work items is the natural shape here. A tree or a "work items and direct links" query loads too, and the board flattens it to the distinct items it returns, but the types this guide is about sit outside every hierarchy, so a flat list says exactly what you mean and nothing more.
• ORDER BY the type's order field, ascending, or no ORDER BY. The board derives the order field for each type: your process's own order field when the type carries it, otherwise the other platform field. The demo process inherits from Scrum, so its own order field is Backlog Priority (Microsoft.VSTS.Common.BacklogPriority). Support Request is a custom type without Backlog Priority, so once Stack Rank (Microsoft.VSTS.Common.StackRank) is on the type, Support Requests order by Stack Rank, and that is the field this query sorts by. Sorting by the order field keeps the board, the List view and the query results page telling the same story. Without the clause, the board adds that order to the query it runs. A query sorted by anything else shows that order and reordering is off.
• A type that lacks the field is shown and never reordered. The board derives the order field per type: a card of a type that carries neither Stack Rank nor Backlog Priority moves between columns and lanes, cannot be dragged within a column, and its menu says why. Nothing is written into a field the type does not carry. Ask an administrator to add the process's field to that type under Organization settings > AnyKanban > Fields (Reordering), as Prerequisites describes.

Risks in the demo organization live in Core Insurance, not in Claims Platform. Widening the board to include them is a query edit and nothing else: add 'Risk' to the type list, widen the project clause to IN ('Claims Platform', 'Core Insurance'), and turn on Query across projects in the query editor. Without it, Azure DevOps scopes the query to the project it is saved in. The board needs no change at all: it reads and writes items in every project the query returns.

Screenshot pending: The backing query in the query editor: flat, several types, ordered by rank

Building the board

1. In your project's left navigation, open Boards and select AnyKanban.
2. Select New board. The suggestions gallery opens. Choose Use existing query, and the board settings panel, titled New board, opens on General.
3. Board name. What the team calls this work, for example Support desk.
4. Backing query. Pick the saved query. Queries are listed with their folder path, and only the first two levels of the query tree are offered, so keep board queries near the top of Shared Queries.
5. Work item type. Pick Support Request. This choice supplies the columns, and it is the one decision on this panel you should make deliberately: pick the type whose flow the board is meant to show.
6. Card order. The row appears once the type is chosen and names the field the type orders by. Nothing is chosen here. In the demo organization, whose process inherits from Scrum, Support Request carries no Backlog Priority, so with Stack Rank on the type the row begins Support Request orders by Stack Rank because it does not carry Backlog Priority, the order field of your process. While the type carries neither field, the board has only the process's Backlog Priority to look for, and this query sorts by Stack Rank, so the row says the query controls the order. A query with no ORDER BY gets a different sentence there: the type does not have Backlog Priority, with the page where an administrator adds it.
7. Select Create, then open the board from the list.

The columns are the Support Request type's own states, in state-category order: New, Triage, In Progress, Waiting on customer, In Review, Done. Nothing here is hardcoded and nothing is invented. Waiting on customer is a state this organization added, and it becomes a column because the process says it exists. The Rejected state does not become a column: it belongs to the Removed category, and removed-category states stay off the board exactly as they do on native boards.

Then open Settings and make the board readable at a glance:

Two things about card fields on a board like this. Work Item Type is not available as a card field. Like the title, the ID and the state, it belongs to the card's own frame rather than to the list you configure. On a board carrying several types you still tell them apart at a glance: each card shows its own type's icon beside the title and its own type's color on the left strip, so a support request, a risk and a test case look different as long as your process gives them different icons and colors. If Azure DevOps cannot describe a type, for example one that exists only in another project, its cards show a plain square where the icon would be. To group the types rather than just mark them, use swimlanes by type or the List view's Type column. And the counter in a column header counts every item in that column, including the ones your filter is currently hiding, because a work-in-progress limit measures real work in progress not what you happen to be looking at. Nothing is ever blocked; the counter turns red above the limit and that is the whole mechanism.

Telling the types apart, with swimlanes by work item type

On a board that carries four or five types, the most useful grouping is usually the type itself. Open Settings → Swimlanes and, in the simple-mode box at the bottom, enter the reference name System.WorkItemType. Leave the named lanes above it empty, because lanes with conditions take precedence over simple mode whenever both are filled in.

The board then renders one row per distinct type in the result set, in alphabetical order, each with its own header, its own collapse chevron and its own count. Support requests, feedback and test cases stop competing for the same column.

Three things to know before you turn this on:

• Do not drag cards between type lanes. In simple mode, dropping a card into another lane writes the lane field, which here is the work item type, so the drop asks Azure DevOps to change the item's type. Depending on the two types and your permissions, the service may accept that change or refuse it. If it refuses, the card returns to its own lane and the server's explanation appears in a message. Use type lanes as a grouping, not as a control.
• The work-in-progress limit does not split by lane. Every lane row's In Progress header shows that lane's own count and, beside it, the whole column's count against the limit, which is what a work-in-progress limit is supposed to measure, the same as native swimlanes.
• Some affordances step aside while lanes are on. The New item button on the first column and in-place editing of a WIP limit from the column header are both offered only on the unlaned board. Everything else works as usual: dragging between columns, reordering, inline field edits and the right-click menu.

Cards whose state is not a column of the board's type appear in an Unmapped column at the right of their own lane row. The next section explains why.

When the state models do not line up

Put four types on one board and their state models will not agree. This is where AnyKanban makes a deliberate choice, and it is worth understanding rather than working around.

Columns follow exactly one type, the one on the General tab. When the query also returns other types and at least one of their cards is in a state that has no column, a warning card appears above the board:

Some cards have work item types whose states do not match the columns for “Support Request”. They appear in Unmapped: Closed, Design, Open, Ready. Filter the query to matching work item types, or review those cards in Unmapped.

The list after the colon names the states that actually stranded cards on your board. On the demo board it is those four, the states of the impediments and test cases.

Behind the warning is the rule the board follows: a card is placed by its state name, not by its type. If an item's state is one of the board's columns, it goes into that column no matter what type it is. Only items in a state that has no column go to Unmapped, and the column is drawn only while the board holds at least one such item.

On the demo board, widened to include Risks, that works out like this:

Feedback and Risk share enough of the support desk's vocabulary to sit in ordinary columns and be managed there. Impediment (Open / Closed) and Test Case (Design / Ready / Closed) speak a different language, and the board says so instead of guessing.

Why Unmapped is a feature

The alternative designs are all worse. A board could drop those items silently, and then the query and the board disagree, and nobody notices until an audit. It could invent columns for every state of every type, and then the board stops being a picture of one flow. It could refuse to load, and then a single stray item costs everyone their board.

Instead: the query is the contract. Everything the query returns is accounted for somewhere.

• Unmapped is not a drop target. You cannot drop a card onto it, because moving a card there would have no state meaning. Dragging a card out of Unmapped into a real column writes that column's name as the item's state, which only succeeds if that state exists for that item's own type, and otherwise comes back with the server's own explanation.
• The column appears only when the board holds an unmapped card. An all-one-type board never shows it. Once it is there it stands in every lane row, empty with a count of 0 in a row that has none, and the filter bar does not take it away.
• The fix belongs to the query or to the type. Narrow the query, split the board in two, or accept the bucket. The board will not change your process to make itself tidier, and it never adds a state, a field or a rule to make an item fit.
• Removed-category items are handled the same way. A rejected support request is hidden from the board, exactly as on a native board, and a note above the board counts them and points at the List view. Hidden, counted, never silently gone.

The List view is the complete answer

The List view renders the whole query result, meaning every card on the board, everything in Unmapped and the removed-state items the board hides, as a dense table, ID, Type, Title, State and Tags unless the board's settings choose other columns, in the query's own order. Rows drag to reorder through the same rank field as the board.

That is the surface to use when someone asks "what is actually in this queue?". Turning swimlanes on does not hide anything from the board either: whenever any card on the board is unmapped, the Unmapped column appears at the right of every lane row, and each row's Unmapped holds that row's own cards. The impediments and test cases stay on the board, inside the row for their type.

Both layouts show everything the board holds. Turn swimlanes on when you want each type in its own row; leave them off when you want the inline New item button and WIP limit editing from the column header.

Making the service level visible

A support board that does not show its clock is a list with extra steps. Three settings do the work.

Card styling. The demo board carries two rules, and both read tags. SLA breached matches a card whose Tags contains sla-breach. Blocked, below it, matches Tags contains blocked and paints the two blocked impediments a brighter red. To build the first one, open Settings → Styles, select Add rule, name it SLA breached, pick red from the palette, then Add condition: the Tags field, operator contains, value sla-breach. Matching cards get a faint red tint behind them (the left strip keeps showing the work item type).

Or read the date instead of a tag. A tag is only there when somebody remembers to add it. If your requests carry the SLA date, a rule can compare the date itself: SLA due, operator <, value @Today matches every request whose due date has passed, tagged or not. The demo board does not carry this rule. On the demo data it would pick out the same two requests the tag rule does, because they are the two whose SLA date has already passed.

How the rules evaluate, in the order it matters:

• All conditions of a rule must match, and rules are evaluated top-down, and the first match wins. A card is never painted twice, so put the rule you most want to see at the top.
• @Today accepts day arithmetic. For a due soon warning beside the date rule, add an amber rule with SLA due < @Today+2 and keep it below the red date rule. A card already past its date matches the red rule first and stops there, so the amber one only catches cards due today or tomorrow. @Me resolves to the signed-in user.
• A typed date means the start of that day in your own time zone, the moment @Today names on that day. SLA due = 2026-10-10 matches any time on 10 October. < 2026-10-10 means before that day begins and > 2026-10-10 means after it begins, so a card due at 09:00 on 10 October matches > as well. A text or picklist field that holds a date written the same way, such as a list of release dates, is read as that day too.
• An empty value matches nothing. A support request with no SLA date does not accidentally look breached. It looks unstyled, which is its own signal.
• On Tags, contains means "has this tag". A rule on Tags contains sla-breach matches the whole tag, case-insensitively, not a fragment of one.

Tag colors. On the Tag colors tab, pick a color per tag name: sla-breach, regulatory, complaint. Tag pills render only when Tags is one of the configured card fields, and matching is exact on the tag name.

Definition of done. On the Columns tab, give Done a definition of done. It accepts bold, lists and links, and it surfaces as an info icon in the column header that opens on hover or keyboard focus, which is where "resolved" gets defined once instead of in every stand-up.

On the card itself

A support request card ends in one row of chips. The related-work chip opens the delivery work the request triggered, meaning the backlog items it is linked to, each with its current state, so you can see whether anything is actually happening without opening the item. Tasks and linked test cases can join the same row once you tick Show tasks on cards on the Annotations tab and Show test cases on cards on the Tests tab of board settings. Both start off on a board like this one. Once they are on, child tasks get a chip with a count of how many are done, which is the honest measure of how far a request has really got, and test cases get a chip of their own, so the regression evidence sits next to the work it covers. A completion count is shown even when the linked delivery item is undecomposed. It then reads 0/1, the item counting as itself. That is an answer rather than an empty value: the delivery work exists and nobody has started or broken it down yet. AnyKanban only ever adds Related links to backlog items, never parent/child. A support request can point at one team's feature and another team's backlog item at the same time, and nothing you do here changes the hierarchy those teams' boards depend on.

What stays untouched

• Your process. Building this board adds no field, state, rule or backlog level, and none of these types is moved onto a backlog. Nothing about how the work is configured changes because it got a board. AnyKanban changes a process in one place only: on the Fields tab of the organization settings page, it can add a field a board needs, such as Stack Rank, to a type in an inherited process, and only after an administrator has reviewed the plan and selected Execute plan. Prerequisites describes it.
• Other people's boards. Manual ordering writes the order field the type derives. None of these types sits on a backlog, so no native board or backlog reorders because of it, and a second AnyKanban board over the same items shares that one order by design.
• Permissions. The board reads and writes as the signed-in user. Anyone who cannot edit a risk today still cannot; a rejected write reverts the card and shows the server's explanation.
• Your data. Board definitions, your own view preferences, organization-wide settings and aggregate usage counters (numbers only, never a work item, title, query or person) are stored in your Azure DevOps through the Extension Data Service, and so is a board baseline when somebody sets one, which records the ids, titles and lane values of the cards at that moment. Nothing leaves your organization. Security and data handling lists every document.

Troubleshooting

Related pages

• User Guide: everything the board does, organized by task
• Prerequisites: the order field, the query and the permissions an administrator must put in place first