# Why a column dims while you drag

**Short answer:** before you drop, the board has already asked Azure DevOps
whether that state would be accepted, for this work item and for you. A dimmed
column is the server's own refusal, not a rule AnyKanban read and interpreted.

## What the board actually asks

Three moments trigger the question: picking a card up, opening the card's
menu (by right-click or with the card's ... button), and opening the state
picker on the card. The board then asks the server about every other column in
parallel, with *would `System.State` = "In Review" be accepted on this item?*,
using validate-only work item updates. The server evaluates its rules and answers;
nothing is written.

Answers are cached per work item revision, so picking the same card up again
costs no calls at all. The first pick-up does cost one call per other column: on
a six-column board, five.

## Why the server answers instead of the extension

Transition restrictions in an inherited process can be scoped to users and
groups. A rule that stops *you* moving an item to Done may not stop the person
sitting next to you. Reading the process and reproducing its rules inside the
extension would give the wrong answer for half the people looking at the same
board, and would need permissions AnyKanban deliberately does not ask for.
Asking the server means the verdict is evaluated for the signed-in user, with no
rule parsing on our side.

## Which refusals dim a column, and which do not

Only a genuine transition restriction dims. The detection is structural: the
rejection has to name `System.State` and flag the value as not being one of the
allowed values.

A rule that merely requires a field, such as "Reason is required when moving to
Done", deliberately does **not** dim the column. You could satisfy that rule after the
drop, so pre-blocking it would take away a move you are entitled to make.
Instead the drop is attempted, the server refuses it, and the card reverts
carrying the server's own message.

## When the check cannot run

Gating fails open. A network problem, rate limiting or an unexpected error shape
leaves no verdict at all; columns nobody could ask about count as allowed, and
the board falls back to its ordinary behavior: attempt the drop, and revert with
the server's message if it is refused. A failed probe never blocks a drag.

## What it means in practice

- A restricted column renders at 35 % opacity with the tooltip **Transition
  restricted by process rules**. The drag preview never enters it, and releasing
  the card on it cancels the whole drag: the card returns to where it started,
  not to the last position the preview showed.
- The same verdicts filter the card menu's **Move to column** list and the
  state picker on the card, so neither offers a state the server said it would
  refuse.
- A move refused *without* a dim was a different kind of rule. Open the item's
  form, satisfy what it asks for, and set the state there.
- There is no switch that turns gating off, deliberately: the verdicts are the
  server's own, evaluated for you, and they fail open: when a check cannot
  run, nothing dims, the drop is simply attempted, and a rejection reverts the
  card with the server's message.
- No probes run in an as-of snapshot: the snapshot is read-only, so there is no
  drag to gate.

![A column your process rules would reject, dimmed mid-drag](https://anykanban.com/docs/_img/transition-gating-dimmed.png)

## Related

- [Why some items sit in Unmapped](https://anykanban.com/docs/concepts/why-items-sit-in-unmapped/)
- [Why rejected work is hidden but counted](https://anykanban.com/docs/concepts/why-rejected-work-is-hidden/)
- [User Guide](https://anykanban.com/docs/user-guide/)