Views

A view is a name, a kind, one grouping property, a set of filter rules and an order. That is all it holds. It owns no tasks, so making one, changing one or deleting one never touches your work.

The two kinds

Kind	What you get
Board	Cards in columns, one column for each value of the grouping property — in the order every view shares, or in the order the Sort button asks for.
List	One row for each task, in the one order every view shares — or in the order you press a heading for. No columns, no grouping.

The same tasks either way. A filter, the card view, the card order and the sort are shared by both, so switching a view between them changes the drawing and nothing else — a board sorted by Due is still sorted by Due when it becomes a list. See The list.

The columns of a board

The columns are the options of the grouping property, in that property’s own order. Change the order and every view using that property changes with it, because the order belongs to the property everybody shares — not to one person’s board.

What you start with

A new project has two: Board, grouped by Status and marked main, and Phases, grouped by Phase.

The main view is the one a board opens on when nobody in that browser has picked one, and it is the one view that cannot be deleted. Everything else about it is ordinary.

Any view can take the word. Settings → Views puts Make main on every other row, and one click moves it — the word is given, never taken away, because a project always has exactly one. It is for the owner and admins, like deleting a view.

How the columns are worked out

Grouping property	Columns you get
select	one per option, in the property’s option order, plus No status at the end
person	one per project member — agents included — plus Unassigned
checkbox	exactly two: the property’s name, and Not <name>

The “nothing yet” column (No status, Unassigned) only appears when something is in it, or when it is the only column there is. A checkbox never gets one, because off is a value, not emptiness.

Group by a person property to see the workload

Group by Assignee and every column is one person — or one agent. It is the fastest way to see who is carrying what, and it needs no new feature, because the columns are just that property’s values.

Adding a view

The + at the end of the view strip opens a small panel: a name, Shows as — Board or List — and, for a board, a chip row of every property that can group one. Leave the name blank and a board becomes By status — the property name, lowercased — and a list becomes List.

If no groupable property exists yet, it says so: “Create a select, person or checkbox property first.” That stops a board only. A list groups nothing, so it can be made on a project that has no such property at all.

The + is the only place a view is made. Settings → Views is where you rename, regroup, change the kind, change the order and delete.

The order of the views

Drag a pill along the strip at the top of the board, or drag a row by the grip on its left in Settings → Views. It is one order, shared by everybody on the project, so moving a view in either place moves it in both.

A pill stays a button first: the drag starts only once the pointer has travelled, so a click still picks the view. The settings page answers the keyboard as well — Space lifts a row, the arrows move it, Space puts it down.

Changing the kind

Settings → Views, the Shows as dropdown. It saves the moment you change it and it asks nothing, because nothing is lost either way: a board that becomes a list keeps the property it grouped by, unread, so turning it back restores the same columns. The “Columns by” dropdown disappears for a list rather than greying out — a disabled control is a question with no answer.

A list can outlive its grouping property

A property cannot be deleted while a board groups by it. A list is not counted, because a list never reads one. Turn a board into a list and the property it remembers is free to go; the list goes on drawing rows, and turning it back into a board asks you for a new property.

Renaming, regrouping, deleting

Settings → Views (/p/{project}/settings/views). The name saves on blur; the “Shows as” and “Columns by” dropdowns save the moment you change them; the grip on the left changes the order and Make main moves the word. Deleting is for the owner and admins and asks in the row:

Delete the view Phases? The tasks stay; only this way of looking at them goes.

Two limits worth knowing now

A view is not in the URL

The board’s address is /p/{projectId}, and only the open task is in it (?task=…). Which view you are looking at is remembered in your browser, per project, not in the address bar — so you cannot send somebody a link to a particular view. Settings pages do each have their own address.

One card order, shared by every view

There is one order for the cards in a project, not one per view. Move a card up in Board and it moves in Phases too, and a row moved in a list moves on every board. It is a known limit, listed on the roadmap, and it is the price of a drag writing exactly one row. A list is the one screen that shows that order whole.

A view that groups by a property you delete

You cannot delete it — while a board groups by it. The server refuses and names the view, because the alternative is a board that silently stops having columns. Point the view at another property first, or make it a list, then delete.

What a filter does to the columns

If a view’s filter names its own grouping property, the columns that rule excludes disappear — they are not drawn empty. An empty column you could still drop a card into is a trap: the card would vanish the moment it landed. See Filters.

The listOne row for each task, the order every view shares, and where its columns come from.

The boardDragging cards and columns, adding a task, and what the top bar is telling you.