Docs › Share and navigate

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).

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). 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 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:

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) 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 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).

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), 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 says, so no board is shown to you and then taken away.