AnyKanban

Docs › Concepts

Why some things need a field of your own

Native Azure Boards lets an admin add a column that is not a state, split a column into Doing and Done, and drag cards into free-form swimlanes. On most boards AnyKanban does the first two, asks for a field of your own for each, and deliberately does not do the third: its swimlanes are rules over fields the cards already carry. A board filed under a team is the exception. It can wear that team's own layout, swimlanes included, and then needs no field of your own. This page explains where that line is and why it sits there.

Columns are yours; states are what they stand on

By default a board's columns come from one work item type's state model, read from your process at load time: one column per state, named as the state. Nothing to configure, and right for most boards.

You can also define the columns yourself: name them what your team calls them, and put several columns over one state, the way the native board renders New | Analysis | Development | Testing | Done over three states. Moving a card from Analysis to Development then changes no state at all. It changes only where the card sits, and that has to be written down somewhere (see below).

Two things hold either way:

The reason columns are configured rather than per team is that a board here is a view of a query, which can span projects and teams. A per-team column list has no meaning across that; a list the board owns does.

A board filed under a team

A board filed under a team may take its columns and swimlanes from that team's own Kanban board, hidden fields included. Let it wear that team's layout and you need no custom field at all for several columns over one state, because the team's board already has one, and the board follows it. Of the three reasons in the next section, two stop applying once a board declares exactly one team, and the third becomes the condition rather than the objection.

On every other board, the field is yours to add.

Where native keeps its answer, and why we do not go there on other boards

Native stores extra-column placement, Doing/Done and lane assignment in hidden fields whose names look like WEF_<guid>_Kanban.Column. On a board that is not filed under a team, no part of AnyKanban names or writes one, and that is a deliberate refusal rather than an oversight:

A board that wears a team's layout is the one exception, as the section above says. When you move a card there, it writes that team's own column, Doing/Done and lane fields, because that team's board is the one it shows. It reads their names from Azure DevOps when the board loads and never stores them in the board's settings.

Storing the placement privately inside the extension was considered and rejected for a different reason: it would drift the moment someone edits the item elsewhere, orphan entries when items fall out of the query, and be invisible to WIQL and to charts. Board placement that a query cannot see is not really data.

And it is refused rather than merely discouraged. Every board field the product can write, meaning the done flag, the swimlane field, the fields shown on cards and the fields lane rules test, is checked when the board is saved, and a WEF_ reference name is rejected with an explanation instead of stored. That includes importing a board from a file, which is the path where the field names come out of JSON and nobody types anything at all.

So: a real field, that you own

Two capabilities need a place to remember something a state cannot express, and both bind to a real field on the work item type, added once by an admin (Prerequisites §4) and proposed or picked from a list in board settings, never typed, so a stored name is always one the service reported.

Several columns over one state need to know which of them a card is in. That is a text field. Once the Fields tab of the organization settings page has created AnyKanban's own field pairs (AnyKanban Board Column 01 with AnyKanban Board Column Done 01, and so on), board settings propose a free pair for the board and reserve it when you save. Two boards that bind the same pair over the same work items overwrite each other's card positions, which is what the reservation prevents. Deleting the board hands its pair back. You can still pick a field yourself, for example so that two boards move cards together on purpose. Without a field the board simply keeps one column per state and says so; a layout where every state has exactly one column needs no field at all, however you name the columns.

Split columns, one state in two situations, bind to a boolean field: the Done half of the same pair, or one you pick.

The payoff for that one setup step is that the placement is queryable and chartable. You can ask "how many change requests sat in Done inside In Review last month" in WIQL, which is not a question you can ask of a hidden board field. It also travels through the same concurrency-safe write pipeline as state and rank, so there is one failure model rather than two.

Without a configured field the split option does not appear, and a multi-column layout falls back to one column per state with a message naming what is missing. Neither degrades into something half-working.

Neither field is written by a board that does not need it: a board whose columns are one-per-state never touches the column field, so it cannot disturb the boards over the same work item type that do use it.

The order field is the same class of prerequisite for the same reason (Prerequisites §2): the order you drag cards into is real data, written to a real field, visible to the backlog and to the query results page, rather than a private opinion this board holds about your work.

Swimlanes need no dedicated field. Lanes are rules over fields you already have, so what matters is that the fields your conditions name exist on the type.

Why adding the field is your administrator's click

AnyKanban can add the field for you, on the Fields tab of the organization settings page, after showing your administrator the exact list of operations, and only when they press Execute plan.

The board never writes to your process. The only path that can is that one page, and a build-failing test pins the chain of code that reaches it, so a process write cannot be triggered from a board, a card, or the settings panel of a board.

The setup follows four rules:

  1. A process is shared by every project using it, so the plan says which process it will change before it changes it, and only somebody who may edit that process can run it. Azure DevOps enforces that, not us: AnyKanban attempts the change and shows you the service's own answer, because knowing in advance who may edit a process would need permissions this extension deliberately does not ask for. A step the service refuses stays listed as still to do, and when it refuses every step the page says that nothing changed.
  2. It must not arrive without your consent. Not for want of permission: Azure DevOps covers process customization under vso.work_write, one of the four scopes the extension already asks for, and there is no separate process scope to decline. The install prompt therefore does not identify field setup separately. Nothing happens until an administrator reviews the plan on the organization settings page and clicks Execute plan.
  3. It is not symmetrically undoable. Adding a field is easy; removing one after items carry values in it is not. So every field the setup creates starts empty and off the work item form, and an empty field IS removable, which is the honest half of that sentence. AnyKanban itself never removes or deletes a field; that stays your act, in your own portal.
  4. The choice is not obvious. So it is shown rather than made. The plan is on screen before it runs, each process can be unticked, the ordering field it proposes is your process's own, and the manual path in Prerequisites is documented too. You learn that a choice exists, which is what a tool that guessed would have taken from you.

Which types the plan covers. Every regular type outside a backlog level (not the utility types Azure DevOps keeps for test plans, test suites, shared steps, code reviews and feedback, nor the copy of one that your process has customized, which Azure DevOps gives a name of its own), and a backlog-level type only when a board uses it or a board's settings sent you to the page with a link that names it. The page reads the boards it can: the shared boards of your organization, and your own. A colleague's personal board is private to them, so its type reaches the plan through the link its settings offer. A board's settings offer that link where they say a type has no field for placing cards in columns, for splitting a column or for ordering cards, or that every column field is taken. It opens the Fields tab with the process and the type already named, so the plan you land on includes them. If the boards cannot be read, the page says so instead of saying there is nothing to set up. A backlog-level type no board uses is left alone: its fields belong to the backlog's own board.

What it will never do, from any surface: change a state, a rule, a backlog level or a work item form, create a process, delete or remove a field, touch one of Azure DevOps' own locked processes, or move a project from one process to another.

What the board does instead is degrade in a way that names the problem. Without the order field, reordering switches off and the board says so rather than silently ignoring your drags; without a done-flag field the split option is simply not offered, and without a column field a multi-column layout stays one column per state. The clicking stays yours, but you are never left guessing which of the two you are looking at.