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.
