# Who sees which boards

Every board you make is for somebody. When you create a board from a template,
the confirmation asks **Where should this board appear?** and offers **My board
list**, **A team's group** or **Project board list**. AnyKanban then arranges the
board list accordingly. A board started with **Use existing query** or **Start
blank**, or with **Save as board** from a query's board, goes to the project
board list without that question, unless its query is saved in *My Queries*.
Only you can read a query there, so that board goes to **My board list**, and
the settings panel says so under the query before you create it. Either way
the answer can be changed later with **Move to…** without losing anything, by
you or by anyone else who can change the board (see
[Who can change a board](https://anykanban.com/docs/share-and-navigate/who-sees-which-boards/#who-can-change-a-board)).

## The three answers

**My board list.** The board is in your own set. Nobody else's list shows it.

**A team's group.** The board stands in that team's group in the board list and
reads that team's backlog, so it shows that team's work. Choose this when the
board belongs to how one team works: their backlog, their bugs, their intake
queue. The team picker offers every team of the project, whether or not you are
a member of it, exactly as the **Create a dashboard** dialog in Azure DevOps
does.

**Project board list.** The board is in the project's list. Choose this for work
that crosses teams: an initiative spanning three squads, a compliance view over
several areas, anything a single team's board could not draw.

Under the two shared answers, a note says who will find the board, in the
terms of the rule AnyKanban applies (see
[How the list is arranged](https://anykanban.com/docs/share-and-navigate/who-sees-which-boards/#how-the-list-is-arranged)). For a board that reads
no team it says *Everyone who can read work items in the project's top-level
area will find this board in their list.* For one that reads a team, such as
Claims Intake, it says *People who can read work items in one of the areas
selected for Claims Intake will find this board in their list.* Where that
team's work is defined by a field other than **Area Path**, it says *People
who can see the team Claims Intake will find this board in their list.*
instead. Each ends with *Azure DevOps still limits the work items each person
sees on it.* **My board list** has no note, because nobody else finds the
board there.

When you delete a shared board, the question names the same people as the
ones who will lose it: *Everyone who can read work items in the project's top-level area will
lose this board.* for a board that reads no team, and *Everyone who can read
work items in one of the areas selected for “Claims Intake” will lose this
board.* for one that reads Claims Intake. Where that team's work is defined
by another field, it says *Everyone who can see the team “Claims Intake”
will lose this board.* Which of the last two is true depends on an answer
from Azure DevOps, so until it arrives the question reads *Finding out who
will lose this board…* and **Delete** waits. That is usually a moment, and
no wait at all for a team the board list has already asked about. A board
that reads a team Azure DevOps does not show you, such as one that was
deleted, may be in nobody's list but its creator's, so its question says *If
the team this board reads was deleted, nobody else will find the board in
their list, so no one else will lose it.* It says so as soon as your list of
teams is in, and AnyKanban asks nothing about a team that list does not
contain.

## How the list is arranged

The list follows the shape of the Boards directory in Azure DevOps, where
**My team boards** is open and **All team boards** is a collapsed list of every
team in the project.

- **Your teams first**, one group per team you belong to, open.
- **Project boards**, with their folders.
- **My boards**, your own set.
- **All team boards**, last and collapsed. It holds the boards of every other
  team in the project, one heading per team. A team with no boards has no
  heading. Open it once and it stays open for you until you close it; that
  choice is yours alone and is kept in your Azure DevOps, never in the
  browser.

Team membership organizes the list. It does not decide what is in it. The
work items you may read do, and Azure DevOps answers that, not a setting of
ours:

- **A board that reads a team**, in that team's group or in the project list,
  is listed for people who may read work items in at least one of the team's
  area paths.
- **A project board that reads no team** is listed for people who may read
  work items at the project's root area, its top-level area path.
- **Every board is listed for the person who created it.** A board you file
  under a team you are not in stays where you can find it.

So a colleague outside the team who may read its area, a manager or someone
in the PMO, finds the team's boards under **All team boards**. A contractor
who may read only their own team's area finds that team's boards and not the
others'. Azure DevOps shows such a person every team and every area path of
the project and hides only the work items, which is why AnyKanban asks about
the work items rather than about the teams.

AnyKanban asks about the area paths a team names in its own settings, not
about the areas beneath them. A team that owns the project's root area, as a
project's default team usually does, therefore has its boards listed for the
people who may read work items at the root, the same people a project board
is listed for. A team whose work is defined by a field other than **Area
Path** has no area paths to ask about, so its boards are listed for everyone
who can see the team, which Azure DevOps lets everyone in the project do.

When the list opens, a board that reads a team appears once Azure DevOps has
answered for that team. It is never shown first and taken away after. If
every board is still waiting for its answer, the list shows that it is
loading. If the project has boards and none of them is in your list, as for a
contractor who may read only an area path that no board reads, the list says
*No boards in your list yet.* **New board** in the header still starts a
board of your own.

Every row carries the same pencil, **Move to…** and trash icon, wherever it is
listed. Whether they change the board depends on the board and on you, as
[Who can change a board](https://anykanban.com/docs/share-and-navigate/who-sees-which-boards/#who-can-change-a-board) explains.

The groups of teams you belong to start open, and **All team boards** starts
shut. Each heading shows which with its arrow, and how many boards the group
holds, so a board you just filed under a team you are not in is counted on
**All team boards**. Click a heading to open or shut it; the list remembers
your choice.

## Which team's backlog a board reads

A board over a backlog level, such as Epics, Features or Product Backlog Items,
answers a second question when you create it from a template: **Which team's
backlog does this board read?** Pick a team, or **No team**, in which case the
board reads the project's own configuration. A board that reads a team follows
that team's levels, the types on them and how its bugs behave, and leaves out
work outside that team's area and iteration. Where you list the board does not
change that answer. On any other board, the confirmation names a team only
through **A team's group**.

The two answers are independent with one exception: a board in a team's group
always reads that team. A board in the project list or in your own set can read
one team's backlog or none. So when **A team's group** is selected and you set
the team question to **No team**, the choice moves to **Project board list**, or
to **My board list** where the project board list is not offered to you.
Naming a team again leaves it there. **Move to…** does the same.

## What filing does not do

**Listing a board for others does not decide who can read it.** A link to a
board that is not in your list does not open it. AnyKanban says *This board
does not exist, or you don't have permission to read the work it shows.*,
which does not say whether the board exists or whose it is. A link to a board
that really does not exist gets the same sentence after the same wait, so the
two cannot be told apart from the answer or from how long it took. The board
AnyKanban reopens for you, your default or the one you had open last, follows
the same rule: if it is no longer in your list, AnyKanban passes over it
without a message, as it does a deleted board, and opens the other one or the
list. It waits only for Azure DevOps's answer about that one board, never for
the rest of the list.

The person who created a board always opens it from its link. None of this
keeps a board's definition from anyone: the definitions of shared boards, a
name, a query and some settings, are readable by anyone using the extension
in your organization outside AnyKanban's own screens. A board in **My board list** is kept in your own
set, so a link to it does not open the board for anyone else.

That sounds like a gap until you see where the real protection is, and it is a
better place: **Azure DevOps decides what each person sees on a board, work
item by work item.** Open the widest board in the project as somebody who may
read one area path and you will see that area's cards and nothing else, with no
setting of ours involved, nothing for an administrator here to get wrong, and
no second place where "who sees what" has to be kept in step with your Azure
DevOps permissions.

So the honest summary: **Azure DevOps decides which work items each person
sees, on every board. The same permissions decide which shared boards are
listed for you, filing decides where, and a team's group also decides whose
work a board shows.**

## Wearing the team's own columns

A team board can go one step further and take its **columns** from that team's
Kanban board: the same columns, the same split columns, the same WIP limits,
the same swimlanes. AnyKanban reads them from the team's board the first time
the board opens after the page loads, and keeps them while the page stays open.
When the team changes their board, yours follows the next time you reload the
page.

Two things are worth knowing about it:

- **It removes a prerequisite.** Several columns over one state normally need a
  custom field an administrator has to add. A board wearing a team's layout
  uses the team's own, so there is nothing to add.
- **Moving a card moves it on their board too.** That is the point, because the two
  boards stop disagreeing, but it is worth saying plainly before you drag
  something.

The columns are not editable here, and neither are the swimlanes, because the board
takes the team's rows in full, so a lane arranged here could never reach it.
Both settings sections show what the team's board has and link to it, where a
team administrator changes them; that keeps one place in charge instead of two
copies drifting apart. The **Columns** section lists each column with the state
it holds for the board's work item type, then *split into Doing and Done* if the
team splits it, and its WIP limit if it has one, as in *Analysis (Active) ·
split into Doing and Done · WIP limit 3*.

The link lands on the **board**, and the settings are behind that board's gear.
That is one click more than we would like, and it is not an oversight: Azure
DevOps' board-settings dialog has no address of its own, and an extension
cannot open it either, both of which we checked rather than assumed. So the
panel names the gear instead of pretending to a shortcut that does not exist.

That board's address carries the team's name as Azure DevOps shows it to you.
Where it does not show you that team, or the list of teams has not loaded,
both sections name the team's board without naming the team, and offer no
link until the name is known.

## Folders, for project boards

A project list that grows past a screenful can be broken into one level of
folders. Type a name when you move a board; the folder exists for as long as a
board is in it, and disappears when the last one leaves. There is nothing to
create and nothing to tidy up.

## Moving a board

Every board row has **Move to…**, and it moves the board for anyone who can
change it. The board keeps its identity, so a link you have shared, a
dashboard widget pinned to it and your default-board choice all keep working.

Moving a board from your **My board list** to a shared list makes it a
shared board that you created, and AnyKanban records you as its creator as
you move it, whatever the board recorded before. That covers an older board
that recorded nobody, and a colleague's board that a team administrator moved
into their own list and now shares again: only you can move a board out of
your own list, so you are the one sharing it, and you can go on changing,
moving and deleting it.

The move dialog asks the same two questions, separately. **Which team's backlog
does this board read?** comes first. The three options below it decide where
the board is listed, and **A team's group** also decides which team it reads,
as the next paragraph says. Moving a board into the project list or your own
set leaves it reading the team it read before.

⚠️ A board in a team's group always reads that team, so moving a board that
read no team **under a team** changes what it shows, not only where it is
listed. The dialog tells you how many cards would stop appearing before you
commit.

⚠️ A board whose query is saved in *My Queries* opens for you alone, wherever
it is listed: Azure DevOps lets nobody else read that query, an organization
administrator included, so anyone else who opens the board sees an error
instead of cards. When you move such a board out of your own list, the dialog
says so. Save the query under *Shared Queries* and choose it in the board's
settings, and the board works for everyone it is listed for. The settings
panel says the same when you choose a query from *My Queries* for a board that
is already listed for others.

## Who can change a board

Anyone who uses AnyKanban in the project can create a board. Changing a
shared board afterwards is offered to fewer people:

| Where the board is listed | Who can change it |
|---|---|
| **My boards** | you |
| A team's group | the person who created it, that team's administrators, and project administrators |
| **Project boards**, whether or not it reads a team | the person who created it, and project administrators |

Project administrators here are the people Azure DevOps gives **Edit
project-level information** in the project. AnyKanban asks Azure DevOps
whether you hold it, so there is nothing to set up here. Members of **Project
Administrators** hold it, and we checked that Azure DevOps answers yes for
them. Members of **Project Collection Administrators** are meant to count as
well, but we have not yet checked one who is not also in Project
Administrators. If a collection administrator finds a shared board read-only,
adding them to the project's Project Administrators group gives them the
answer we checked.

A project administrator can change any shared board they can open. A board
that reads a team Azure DevOps no longer returns, for example because the
team was deleted, is in nobody's list but its creator's and opens for nobody
else from its link, so only its creator can reach it to change or move it.
When its creator opens **Move to…** on it, the dialog says *This board reads
a team Azure DevOps does not show you, such as one that was deleted.* and,
for a shared list, *If the team this board reads was deleted, nobody else
will find the board in their list. Pick another team, or No team, to share
it.* A deleted team and one Azure DevOps does not show you look the same
from AnyKanban, which is why the dialog does not say which of the two it is.
The team choice above those sentences reads *A team Azure DevOps does not
show you*, and once you pick something else you cannot pick it again. Pick
another team or **No team** there and press **Move**, and the board stops
reading the team you cannot see.

A board of a deleted team that also records no creator (see
[Boards with no recorded creator](https://anykanban.com/docs/share-and-navigate/who-sees-which-boards/#boards-with-no-recorded-creator)) is in
nobody's list and opens for nobody, administrators included. AnyKanban has
no way back to it: its link is refused, and **Export** leaves it out, only
counting it in *Boards outside your list were not exported*. Its definition
stays in your Azure DevOps, in the extension's data. So before you delete a
team, move the boards that read it to another team or to **No team**, or
export them. An export taken before the team was deleted is the only way to
get such a board back afterwards: **Import** creates it again as a new
board, recorded as created by you.

Changing means anything that rewrites the board for everyone who opens it:
**Save** in the settings panel, a WIP limit typed into a column header, the
**Level** selector and **Include items with no children** in the toolbar,
**Move to…** (a move into your own list as well), and deleting the board.

Everyone else can still open the settings and read them, which helps when you
want to know why a card is colored the way it is. **Save** is unavailable
there, and the panel says who can change the board, by name where AnyKanban
knows it: *Ana Horvat or a project administrator can change this board's
settings. You can read them here.* On a board in a team's group the sentence
names the team's administrators as well. Most fields still take typing, so
you can try a setting out. Close the panel after that and the dialog says
*These changes cannot be saved. Discard them to close the settings.*, with
**Cancel** and **Discard** and no **Save**. The pencil, **Move to…** and the
trash icon stay on every row. On a board you cannot change, **Move to…** and
the trash icon open a dialog that names who can move or delete it, in place of
the button that would. A WIP limit in a column header, the **Level** selector
and **Include items with no children** say who can change the board when you
select them, and change nothing.

A board records who created it. An imported board records the person who
imported it, so the boards you import are yours to change. The name in the
sentence is the one Azure DevOps showed for that person when they created the
board. A board created before version 0.4.102 says *The person who created
this board* instead, until that person next saves it.

### Boards with no recorded creator

Boards created before version 0.4.70, and boards made with **Open settings**,
**Use existing query**, **Start blank** or **Save as board** before version
0.4.97, do not record who created them. Administrators change those: project
administrators always, and for a board in a team's group, that team's
administrators as well. Everyone else reads them, and on a project board the
panel says *A project administrator can change this board's settings.* The
exception is one of those boards that reads a team Azure DevOps no longer
returns: nobody can open it, administrators included, as
[Who can change a board](https://anykanban.com/docs/share-and-navigate/who-sees-which-boards/#who-can-change-a-board) says.

A board of that age still in your own **My board list** is different: moving
it to a shared list records you as its creator (see
[Moving a board](https://anykanban.com/docs/share-and-navigate/who-sees-which-boards/#moving-a-board)).

If you made one of those boards and want to go on changing it, ask a project
administrator, or make your own copy with **Export** and **Import**. An
imported board is a new board created by you, so a link or a dashboard widget
that points at the old one does not follow it, and Import creates every board
in the file.

### How AnyKanban decides

For a board in a team's group, AnyKanban asks Azure DevOps whether you may edit
that team's own board, so a team administrator gets the answer the team's own
board would give them. Any of the team's boards gives that answer. If a board
wears a team board's layout and that board can no longer be read, for example
because it was removed, AnyKanban asks one of the team's other boards instead.
A team whose boards Azure DevOps cannot list, for example because its backlog
iteration no longer exists, gives no such answer, and AnyKanban then checks
whether you administer the team. Project administrators are recognized either
way, because AnyKanban asks about them separately.

**Save**, **Move to…** and Delete check again when you press them. When an
answer AnyKanban already has allows the change, for example that you are a
project administrator, they go ahead without waiting for the others, since
no other answer could turn that yes into a no. While they do wait, the first
answer that allows the change decides, and the rest are not waited for.

While **Move** or **Delete** waits for that check, its button is greyed and
a screen reader hears that it is waiting for Azure DevOps to answer. A
greyed **Move** or **Delete** does nothing, whether you click it or press
**Enter**, and the choices in the move dialog stay as you left them.
**Cancel** or **Escape** during the wait stops the act: nothing is moved or
deleted when the answer arrives. If the answer is no, the dialog says who
can move or delete the board, where the button was.

If the answer is yes, the dialog stays open while AnyKanban moves or deletes
the board. The button stays greyed, and a screen reader hears *Move, moving
the board* or *Delete, deleting the board*. **Cancel** is greyed too, and
neither it nor **Escape** closes the dialog. What has been sent cannot be
called back, and a move is two writes, so stopping between them would leave
the board in two lists. Once Azure DevOps has answered, the dialog closes
and the board list is read again. If the move or the delete did not go
through, a message says so.

A change to someone's groups reaches Azure DevOps's answer within about a
minute. AnyKanban asks whether you are a project administrator once per page
load, and asks about a team's administrators again each time you open a
board's settings. Reload the page if you have just been made an administrator.

If Azure DevOps cannot answer, AnyKanban offers the change rather than
refusing it. This is a guard against changing a colleague's board by accident.
It is not access control: Azure DevOps keeps no permissions on the board
definitions themselves (see
[Security and data handling](https://anykanban.com/docs/security-and-data-handling/)), and what
protects the work is Azure DevOps's own permission on every work item.

## When the teams cannot be read

If Azure DevOps cannot answer which teams the project has, whether from a
transient failure or a throttled moment, the list is not grouped by team, and
a line above it says so. What is in the list still follows the other answers.
A board that reads a team is listed if you may read work items in one of that
team's area paths, and a project board if you may read work items at the
project's root. Only a definite no from Azure DevOps leaves a board out.

When Azure DevOps cannot answer one of those questions either, the boards it
would decide are listed: a board you use every day must not disappear because
one call failed. Each of these questions is time-bound: every request behind
it gives up when Azure DevOps does not answer in time, and a question left
without an answer counts as one Azure DevOps could not answer. It is asked
again the next time AnyKanban reads the board list, for example after you
save a board or reload the page. A question about a team asks several things
one after another (the team list, the team's area paths, then what you may
read in them), so it can take longer than any one request. An answer about
one team never decides another's.

A board that is still waiting for its team's answer is not listed until the
answer arrives, as [How the list is arranged](https://anykanban.com/docs/share-and-navigate/who-sees-which-boards/#how-the-list-is-arranged)
says, so no board is shown to you and then taken away.