# 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:

- **Every state needs at least one column.** The settings refuse to save a
  layout that leaves one uncovered, because a state with nowhere to go is a
  card that vanishes. Removed-category states are the exception: they are
  hidden from the board exactly as they are natively, with a count above it and
  the full result still in the List view, as
  [why rejected work is hidden](https://anykanban.com/docs/concepts/why-rejected-work-is-hidden/) explains. Anything whose
  state matches no column is parked in
  [Unmapped](https://anykanban.com/docs/concepts/why-items-sit-in-unmapped/) rather than dropped.
- **The state is always the truth.** A card is in the Analysis column because
  its state is Active and its placement field says Analysis; if the field says
  something that no longer exists, the card falls back to the first column of
  its state. It never lands somewhere its state does not allow, and no
  configuration change, whether renaming, reordering or removing a column,
  rewrites a single work item.

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:

- **They belong to one team's board.** The name contains that board's id. A
  board built from a query that spans three teams has no single such field to
  write to: there are three, or none.
- **They are undocumented.** Their shape is Microsoft's internal business, not a
  contract anyone promised to keep.
- **They are not ours.** Writing into another team's hidden board state changes
  how *their* native board behaves, without them asking.

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](https://anykanban.com/docs/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](https://anykanban.com/docs/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](https://anykanban.com/docs/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.

## Related

- [Put two columns over one state](https://anykanban.com/docs/shape-the-board/two-columns-over-one-state/)
- [Why some items sit in Unmapped](https://anykanban.com/docs/concepts/why-items-sit-in-unmapped/)
- [Split a column into Doing and Done](https://anykanban.com/docs/shape-the-board/split-a-column/)
- [Why AnyKanban never writes to someone else's backlog](https://anykanban.com/docs/concepts/why-we-never-write-to-your-backlog/)
- [Prerequisites](https://anykanban.com/docs/prerequisites/)