# Why rejected work is hidden but counted

**Short answer:** items in a **Removed-category** state are left out of the
board's grouping, exactly as they are on a native Azure Boards board. They are
not lost: a note above the columns says how many there are, and the List view
shows them as ordinary rows.

## Category, not name

The board never keys on a state's name. What is hidden is every state whose
**category** is Removed: "Rejected" in the demo process, "Removed" on the stock
Scrum types, and whatever a custom process calls it. Removed states are stripped
out when the columns are built, which is why a board over Change Requests renders
New, Triage, In Progress, In Review and Done, and no Rejected column exists to
drop a card into.

This is the same rule that decides everything else state-related in the product,
and the reason it works on the custom processes our customers actually run.

## Why hidden rather than shown

A removed item is not work any more. Leaving it in a column would inflate the
column count, break the WIP-limit signal, and make a board look busier than the
team is. Native boards made the same call, and matching them here means nobody
has to learn a second rule.

## Why counted rather than silent

Hiding without saying so would make the board disagree with the query that feeds
it, and a reader would have no way to notice. So a small line sits above the
columns:

> Items in removed states are hidden: {count}. See the List view.

The number is the count of loaded items in a removed state. It ignores your
filter, because it answers "what is the query holding that the board is not
showing",
which the filter has no bearing on. When there are none, the line is absent.

## Where they still are

The **List** view is built from the query result order, one row per item.
Nothing is grouped by state, so removed items appear as ordinary rows, as do
the items sitting in Unmapped. The filter applies to the List as well: a
removed item that does not match it has no row there either, while the note's
count stays the same. Clear the filter with **Hide and clear filters** when you
want every row. With no filter on, the List is the complete view of the query,
and the board the process view of it.

In the demo, *Stop asking for documents we already hold* is Rejected on the
business-requests board, and *Decommission the legacy batch clearing interface*
is Rejected on the change-request board. Neither has a card; both are rows in the
List, and both are inside the note's count.

## What it means in practice

- If an item you expected is missing and the note is there, check the List before
  anything else. It is very often a removed state and nothing more.
- If someone moves an item into a removed state while your board is open, the
  next refresh takes the card off the board on the spot. It stays in the List.
- The same reasoning runs through the rollup on cards: a removed descendant is
  counted on neither side of the fraction, because counting it as "not done"
  would make an epic permanently unfinishable.

![The note accounting for items in a removed state](https://anykanban.com/docs/_img/removed-state-note.png)

## Related

- [Why some items sit in Unmapped](https://anykanban.com/docs/concepts/why-items-sit-in-unmapped/)
- [What the rollup counts, and what it excludes](https://anykanban.com/docs/concepts/what-the-rollup-counts/)
- [User Guide](https://anykanban.com/docs/user-guide/)