List views and the data grid

Most of the work you do in Disco Parrot happens on a list. Triage Monday morning. Reorder the work in a sprint. Catch up on what changed while you were out. Sweep a stale owner field off a hundred plans before the planning meeting. The list is where you live, so the grid that draws it has to be quick to read, quick to edit, and quick to share.

Every list in the product (initiatives, plans, bugs, sprints, goals, test cases, documents, projects, portfolios) is rendered through the same data-grid composition. Resizable columns, sortable headers, inline filters, the kind of cell editing you expect from a real spreadsheet but built on top of structured records. The behavior is consistent across every entity, so what you learn on one list applies to all of them.

Sort, filter, share

The first thing the grid is good at is letting you narrow it down to what you actually want to look at. There are two filtering surfaces, and they answer different questions.

The column filter row sits just under the headers. Each one takes a few characters and matches them against the values in that column. It is fast, it stays out of your way, and it is the right tool when you know the word you are looking for. The filter panel opens as a two-column popover with categories on the left (status, owner, project, severity, whatever the entity carries) and the options under each category on the right. Multi-select your way through it and the active filter chips show up at the top of the list, each clearable on its own. Use the column row for quick text searches; use the filter panel when you want to pick a set of statuses and a couple of owners and see the intersection.

Sorting and pagination

Click a column header to sort by it; click again to flip direction. The sort key shows up in the URL alongside the filter, so the order you chose travels with the link you share. Pagination is cursor-based, which means the list keeps scrolling cleanly as records get created and updated under you; the grid does not skip a row or duplicate one when something changes mid-scroll.

Shareable as a link

What matters most is that the entire query (the filters, the sort, the search string, the view mode) lives in the URL. Pin the link in a project doc and the doc still resolves next quarter. Drop it in your team channel and the next person who opens it sees the same list you do. Saved views in Disco Parrot are not a separate record type with their own permissions; they are links. The Built for query page covers the grammar in full if you want the details.

Editing in the cell

You do not leave the list to make most changes. Click a cell on a record you have permission to edit and the cell flips into edit mode in place. The change applies locally the moment you let go of it; the platform writes the update in the background.

The inline editor handles the eight field types that cover almost every value on a record:

• Short text for titles, descriptions, identifiers.
• Number for counts, points, anything that takes a numeric value.
• Dropdown for single-select among a fixed set, like a status or a plan type.
• Combobox when the set is fixed but you want type-ahead to find the value.
• Checkbox for a boolean.
• Lookup for fields that point at another record, with a searchable picker.
• Date for any deadline, start, or target.
• Time for the few fields where the hour matters.

Each one validates its own input. A date field will not accept a free string. A lookup will not let you point at a record that does not exist. Enter commits the change. Escape backs out without saving.

If the write fails for any reason (a permission denied, a stale version, a network blip), the cell reverts to what it was, a toast tells you why, and the rest of your work is uninterrupted. The same goes for a precondition conflict: when someone else changed the record between when you opened the cell and when you committed, the canonical record wins and your view resets, rather than silently overwriting their change.

Bulk editing across every page that matches

Some changes are bigger than one row. Reassign every plan in a project. Move a quarter's worth of work into a new sprint. Close the bug backlog from last release. The grid lets you do these as a single operation rather than a hundred.

Select a few records and the bulk action bar appears at the top of the list with the actions that apply to your selection. Change a status, change an owner, change a date, delete. The action runs once and reports back when it lands.

What makes this work for real cleanups is select all matching. When the selection covers every visible row and there are more pages behind it, an option appears to extend the selection across every page that matches the current query. The grid pulls additional pages until it has every record or hits a ceiling of a hundred pages, which keeps the UI from running away on a query that returns hundreds of thousands of rows. The number shown next to the action ("Select all 247 matching") is the true count, not just the visible one, so you know what you are about to change.

Trash is a filter, not a separate place

Deleting a record does not throw it away. The platform marks it deleted with a timestamp and keeps the rest of the row where it was, including its history. The default list hides those rows so the everyday view stays clean; switching the list into trash mode is the same query with one extra clause asking for rows where the deleted timestamp is set.

This is the same point the Built for query page makes, in a different shape. The trash for a given entity is not a separate inbox with its own schema; it is the same list with a different filter, the same row actions adapted to "Restore" instead of "Delete," and the same bulk operations. A restore clears the timestamp. The row returns to the main view with its history intact, including any version history that captured edits along the way.

What your workflow decides

Two pieces of how the grid looks for a given entity are decided by your workflow, not by the grid itself. The first is which fields show up as columns; the second is how empty cells render.

The grid fields for an entity (which columns appear, in what order, at what widths) are configured on that entity's workflow. An admin picks the fields from a per-entity catalog and saves them. The change applies workspace-wide; every list of that entity type updates with it on the next render. The same catalog drives card fields on the Kanban board and the hover fields on the roadmap, so editing the workflow updates all of them at once.

The second decision is what an empty cell looks like. The workflow's empty-field display toggle decides whether an empty cell shows an em-dash placeholder or the field's label as a hint, on a per-surface basis. The grid renders the choice the workflow set.

Row actions

Each row carries a kebab menu on the title column with the operations that apply to that record. The menu is broken into three small sections so the common moves are easy to reach.

Navigate holds the cross-surface links: open the record's detail page, open it in a new tab, jump to the related plan or initiative. Actions holds the edit-shaped operations: change the status, change the owner, copy the link, delete (or restore, depending on whether the row is live or in the trash). Details is the optional information action, used by a handful of pages that want to surface metadata without opening the full detail.

The contents of the menu are wired per surface. The plans list shows actions a plan supports; the sprint backlog list adds "Move to top of sprint" because that is a sprint-specific move. A reviewer who can read a row but not write to it sees a reduced menu that omits the operations they do not have the scope to run.

The list stays current while you work in it

You are not the only person looking at the records on your list. A teammate moves a plan to In Progress from a chat with the agent, an admin closes a sprint, a Flow run advances a checkpoint. Each of those changes lands on your screen within a second; the row updates in place, the rollup count on the parent updates, the order of the list adjusts if the change affects the sort.

Your own edits do not get echoed back as a flash. The grid recognizes that the change it sees coming back is the change you just made, and leaves your row alone. The list you are reading is current with what is happening across the workspace, and current is the default state, not a button you press.