Put a column in priority order
In Progress holds four business requests and the team needs to agree which one is worked first. Drag Be ready for the 2027 regulatory reporting regime to the top of the column: the order is written to a real field on the work item, so the List view and the query results page show the same order. It is not a private arrangement of your own screen.
Before you start
- This page is about boards over types outside the backlog, where the rank
field exists for the board, so its order is yours to arrange. On a board of
backlog items (stories, PBIs, features, epics) the same field is the
product owner's prioritization, so AnyKanban reads it and does not write it
unless that board's owner deliberately turns it on: by default cards follow
the backlog's order (sorted for you when the query has no
ORDER BYof its own), in-column dragging is inert, and the card menu explains it where Move to top/bottom would be, with Reordering is off because the backlog owns this order when the backlog's order governs the view, or The query controls order. AnyKanban never writes backlog order when your query brings its ownORDER BY. No line above such a board says that the query's sort turned reordering off, because there another sort would not turn it on by itself. To reorder such a board anyway, its query has to show the backlog's order (noORDER BY, or the order field ascending), and you tick Reorder from this board in its settings and confirm. Why we never write to your backlog lists the boards where that setting cannot take effect. Where it can and the query sorts by another field, the sort is all that stands in the way, so a card of the board's own type says Reordering is off while the query sorts by … instead. The Board tab on a query's results page has no settings, so a board of backlog items there is never reordered. - The board's work item type must carry your process's order field, which the board derives for it. Without it a warning sits above the board, … cards cannot be reordered without "…", the order field of their process, an in-column drag does nothing, and the one remedy is Organization settings > AnyKanban > Fields (Reordering). On a board that shows several types, one line lists the other types whose process orders by the board's field but which carry neither Stack Rank nor Backlog Priority, with their project when it is not the board's own, and it follows the cards as they arrive or leave. Those cards sort after the others. A board of backlog items shows no such line: there those cards stay read only even with the field, so adding it would not let them move, and their card menu says why. A type that orders by the other platform field sorts after the others too, but adding the board's field is not its remedy, so the line does not list it: its card menu and the Card order row in the board's settings say which field it orders by. See Prerequisites.
- Reordering is on when the query has no
ORDER BY(the board shows the order field's order) or sorts by that field ascending. A query sorted by anything else shows that order, and a line above the board says The query sorts by …, so reordering is off; the Card order row says the same and how to change it. On the Board tab of a query's results page the same sentence sits behind Order: query in the row above the board instead. On a board of backlog items the line appears only where the sort is all that keeps away a reordering the board's settings allow: Reorder from this board on a backlog level that holds one work item type, or Let Take priorities from … reorder the backlog. - Not an As of snapshot. A filter may stay on; the Notes below say where a card lands while others are hidden.
Steps
- Open the board. The filter bar may stay as it is.
- Press and hold on the card Be ready for the 2027 regulatory reporting regime and start moving; the drag begins after about 4 px.
- Move the pointer up inside the same column. The gap that opens between two cards is the slot the card will occupy.
- Release it in the gap at the top of In Progress.
- Select Refresh in the board header, then open the List tab: the rows come back in the same order, because the query sorts by the same field.
What you should see
The card sits at the top of the column and stays there through the next automatic refresh, because the position is data rather than a local view state. In the normal case exactly one work item is written: the moved card takes a new rank read off its new neighbors, the midpoint when it lands between two cards and a step past the last one when it lands at an end, and the neighbors are left alone.
Notes
When the numeric gap between two neighbors is used up, the board places the cards near the drop again (on a short column, all of them). It stays between the cards it loaded and, at the edge of what it loaded, between the nearest items outside the board. Before it saves, it also reads the items in that stretch that are not in this column, and places the cards around them. It reads, in the moved card's project, the items of its own type, of every other type in the column (a bug among change requests, for example) and, on a board that writes its backlog's order, of every type on that backlog level and, when that backlog is the one for requirements, of the project's bug types. Closed and removed items count too, so one that is reopened is still where it was. So nothing moves past such an item that you cannot see in the column, whether it sits beyond the cards you can see or between two of them. Items of a type that shares the order but appears in neither place, such as user stories on a board of bugs, are not read, and on a board that mixes projects, the items of the other projects are not read. A card with no rank is never given one this way, and a card this board shows but may not reorder stays where it is while the cards around it keep to their own side of it. When there is no room left, the card keeps its order and a message says so. When the read fails, the card keeps its order too, and the message says the order could not be checked, so the move is worth trying again. When Azure DevOps is limiting how many requests you can make, the board cannot read that stretch, so the card keeps its order and the message says to try the move again. Once the pause is over, the same move works. A stretch can also hold more items than the board reads at once: more than 200 items of the types it reads, counting the cards the board shows as well as the ones it does not. The board then reads a smaller stretch around the drop when it can, and when that is still too full, the card keeps its order and the message says there are too many items there. The same move gives the same answer every time, so place the card somewhere else. A move to another column or lane from the same drag is still saved. Your own card's write is the one that is retried and reported if it fails; the background respacing is dropped silently on a conflict, because the next refresh re-sorts anyway. The card's right-click menu does the same job without dragging.
While a filter hides part of the column, a drop lands by one rule, the same one the native board uses: between two visible cards, directly above the lower one, after every hidden card between them; at the top of the visible list, directly above the first visible card; at the bottom, directly below the last visible card. The hidden cards keep their own ranks, and the card's new rank lies strictly between two neighboring ranks of the whole column, so no other card can hold it. Move to position counts the whole column, hidden cards included, so the number it asks for is a position in the full column.
A work item that has never been given a value in the order field sorts after every item that has one: Azure DevOps puts an empty value last, and so does the board. Items of a type outside the backlog usually start out that way, because nothing in Azure DevOps gives them a value. So a card dropped below such an item lands directly above it instead, the last place a value can hold, and is shown there at once rather than moved there by the next refresh. A card with no value of its own cannot be placed below another item without one, because any value would sort it above all of them: a drag there, or Move to bottom or Move to position to such a place, is refused, the card stays where it was, and a message says why. Move to top, or a drop directly below the last card that has a value, gives the card a value and works. A drag of such a card to another column is still saved, and the card takes the place its empty value gives it there.
The List offers the same menu on every row, and there the order entries count the List instead of a column. The List has no columns: its order is the order field across every item the board loaded. So Move to top puts the row first in the whole List, and Move to position asks for a number between 1 and the number of rows, hidden and not yet shown rows included, under the title Move to list position. Move to column from a row moves the item to that column as the card's entry does, but writes no new rank, so the row keeps its place. Rows with no value in the order field follow the same rule as cards: they come after the rows that have one, and a row with no value cannot be placed below another row without one.