# Why AnyKanban never writes to someone else's backlog

**Short answer:** a card links to **existing** backlog work with the **Related**
link type and nothing else. It never links an existing item as its parent or
its child. The items it links with Related have no checkboxes anywhere
either. And on a board *of* backlog items, the backlog's own order is read and
never written, unless someone deliberately turns that on for the board, which
is off by default and covered below. Linking upward can therefore never displace,
reparent or close somebody else's work.

## Where the rule comes from

The cards on these boards hold work item types that sit **outside** the backlog:
business requests, change requests, support requests, risks. If they sat inside
the hierarchy, a native Azure Boards board would already show them and there
would be no reason for this product to exist.

Parent/child links would also have to pick a direction, and the right direction
depends on the relative level of the two items: a feature on a business-request
card is above it, a backlog item is below it. Worse, Azure DevOps allows a work
item **one** parent. "Link this card to that epic" would then either fail or
silently replace a parent somebody else set. Related has neither problem: no
direction, no single-parent constraint, nothing to overwrite.

The consequence is a feature rather than a compromise. One card can legitimately
link one team's epic and another team's feature at the same time, which is
exactly what a demo card like *Be ready for the 2027 regulatory reporting regime*
does, linking two epics in two different projects.

## No checkboxes, on purpose

Linked items share the card's chip row with the task and bug checklists but
behave differently inside it: a linked item has no checkbox and cannot be
dragged, and the only thing you can add there is another Related link, either
to an existing work item or to a new one created in the Azure DevOps dialog.
Planned work shows a progress count; every
other linked item shows a state badge. You do not close another team's epic from
a support card, and no arrangement of the UI should let you do it by accident.

The rollup only ever **reads**. It walks descendants to count them and writes
nothing at any depth.

## What the card does write

The distinction worth keeping straight is *whose work it is*:

- **Its own children**, meaning the Tasks and Bugs checklists. Ticking a box moves that
  child to its own type's completed-category state; dragging a task writes that
  task's own ordering field; **Add task** creates a task under the card, in the
  card's project, area path and iteration path.
- **Its own backlog-level children**, meaning the chip for the level below (a Feature's
  stories, an Epic's features) carries the same checkbox the native card
  draws there: ticking it closes the card's own child through that child's
  process states. The box is always offered and never pre-disabled, because the server
  is what checks the close, and a refusal reverts the tick with the server's
  own message. No drag, and no rank write: the order shown is the backlog
  owner's.
- **A new child it creates.** On a card that is itself a backlog item, the
  add affordance (named for what it creates: **+ Add Feature**) makes a
  brand-new work item of the backlog level directly below the card's own, in
  the card's project, area path and iteration path, with its parent link set
  in the same creation. That is the native quick-add pattern: a newborn has
  no other parent to displace, so nothing anyone else set can be overwritten.
  The rule this page is named for is about **linking existing items**: that
  stays off the list entirely.
- **Items linked with Tested By**, meaning the Test cases section, with the same
  checkbox behavior, on from the start on a board of backlog items or of bugs
  and off on other boards.
- **The card's own work item**: state on a drag, rank on a reorder, the split
  flag and lane fields a drop implies, and inline field edits. Rank carries one
  deliberate exception: on a board **of** backlog items, whether stories, features or
  epics, the ordering field is the product owner's prioritization, so the board
  reads it and never writes it **until you say otherwise**. By default cards
  follow the backlog's order (sorted for you when the query has no `ORDER BY` of
  its own), an in-column drag is inert, and the card menu says why, with *Reordering
  is off because the backlog owns this order* where **Move to top/bottom**
  would be, with *Why reordering is off and how to enable it* beneath it. When
  the query sorts by anything other than the order field, ascending, the board
  is showing the query's order instead, and the menu names that source: *The
  query controls order. AnyKanban never writes backlog order*. Where
  **Reorder from this board** is on and nothing in its list of limits below
  stands in the way, a card of the board's own type says *Reordering is off
  while the query sorts by …* instead, because there the sort is all that
  stands in the way.

The card also adds links and items of its own. **Add related** links an
existing work item to the card with Related, and **Create new** under it opens
the native Azure DevOps dialog for a new item linked the same way. **Add test**
links an existing test case with Tested By, or creates a new test case linked
the same way. **Delete** in the card menu moves the
card's own work item to the project's recycle bin, where an administrator can
restore it. Apart from the Related link itself, which shows on both ends,
nothing here changes a backlog item reached through a Related link, at any
depth.

## When you do want to reorder the backlog from here

The read-only default is a judgment about *whose* order it is rather than a technical
limit, so it can be lifted, deliberately, per board.

**Board settings → Reorder from this board.** Ticking it opens a confirmation
that says what it costs, because the consequence lands outside the board: the
order you write is the order every other team reads, and nothing on their own
backlog will say it came from here. Once it is on, the board carries a
notice that cannot be dismissed, because one person makes the decision, and everyone
who opens the board afterwards inherits it. On a shared board that person is
someone who can change the board: whoever created it or a project
administrator, and on a board in a team's group, that team's administrators
too.

An administrator can also make this the starting point for new boards: the
AnyKanban page in Organization settings has a **Backlog boards may reorder the
backlog** option under **Defaults for new boards**. With it on, a new board
starts with reordering on and does not ask for the confirmation again. Its
notice still appears and still cannot be dismissed. The option is offered to
people with the **Edit instance-level information** permission and shown
read-only to everyone else, as a guard against accidental change.

Five limits are worth knowing before you turn it on:

- **It only unlocks this board's own type, in this board's own project.** A
  backlog item of some other type that the query also returned keeps its
  owner's rank, and so does an item from another project that happens to share
  a type name. On a board whose definition names the project its type belongs
  to, because that is not the project the board is opened from, the named
  project is the board's own: its cards can be reordered, and a card of the
  same type from the project the board is opened from keeps its owner's rank.
  An item added inline on such a board is created in the project the board is
  opened from, so it starts without a rank there.
- **It does nothing when the query sorts by anything other than the rank
  field, ascending.** The board is then showing the query's order, so a drop
  between two rows is not a position in the backlog and there is nothing
  honest to write. A query with no `ORDER BY`, or one that sorts by the order
  field ascending as its first key,
  shows the backlog's order, and there the setting works. While the setting is
  on, the query sorts by something else and nothing else in this list stands
  in the way, a line above the board names the field the query sorts by, and
  so does the card menu of each card of the board's own type.
- **It does nothing when the board's backlog level holds more than one type**,
  for example stories and bugs on the same backlog. The checkbox is still
  there, but the setting unlocks a single type and the cards shown interleave
  two or more, so the board keeps the backlog's order read-only.
- **It does nothing while the toolbar's Level shows a level other than the
  one the query returns.** The cards are then the query's relatives, so a
  position between two of them is a position among items you cannot see.
- **It is not available on an ad-hoc board** opened straight from a query,
  which has no saved definition to carry the setting.

Nothing about this bypasses Azure DevOps. Every write still runs as you, under
your own permissions, and a refused write is reported rather than swallowed.

## When the backlog should follow the business's requests

A second option, separate from the first, lets a shared board of backlog items
reorder the backlog from the order of its requests on a request board:
**Let Take priorities from … reorder the backlog**, on the **General** tab
below **Request board**. It is off by default, a new board never starts with
it on, an imported board arrives with it off, and it asks for a confirmation
before it is turned on. Turning on one of the two options never turns on the
other.

It is also more careful than a drag, because it reaches further. It can move
items on the levels above and below the board's own cards. With the choice its
preview starts with, it moves only items with a request of their own. With
**The whole hierarchy** chosen, it can move every item on the levels it
reaches: an item with a request of its own is placed by that request, the
others follow the item above them, and an item with no request and nothing
above it to follow goes after the items that have one. Either way it moves
only items in the area paths the board's cards use (or, on a board filed under
a team, the team's own) unless the reader adds another area for one run with
**Also reorder these**, and only after a preview that lists every item it
would write. Items of other teams that it passes on the way keep their own
order, and one that has a request is passed only in the direction request
order says. With **The whole hierarchy**, a request an item takes from an item
above it counts as well, and a move down never passes one of their items that
has no request at all. It writes the order field and nothing else, and it
never links an item to a request. See [Put the backlog in the order of its
requests](https://anykanban.com/docs/move-work/take-priorities-from-requests/).

## What it means in practice

- Link freely and link more than once. Multiple links are legitimate, and adding
  one takes nothing away from anyone.
- Remember that a Related link in Azure DevOps is visible from both ends: the
  epic's own Related list will show your card. That is good for traceability and
  worth knowing before you link.
- To actually change a linked backlog item, click its title. The native work item
  form opens, with that item's own process, rules and required fields, which is where
  such a change belongs.
- The board also never changes your process. It reads the process configuration
  and adapts to it; it adds no fields, states, rules or backlog levels. The one
  exception is the field setup on the organization settings page, and it works
  only in an inherited process. There it can create a field, prepare an
  inherited copy of a work item type where the field needs one, and put the
  field on that type. It never adds a state, a rule or a level, and it acts
  only when your administrator has read the plan and presses Execute plan.

## Related

- [What the rollup counts, and what it excludes](https://anykanban.com/docs/concepts/what-the-rollup-counts/)
- [Why some items sit in Unmapped](https://anykanban.com/docs/concepts/why-items-sit-in-unmapped/)
- [Business requests linked to delivery work](https://anykanban.com/docs/guide-business-requests/)
- [Security and data handling](https://anykanban.com/docs/security-and-data-handling/)