Skip to content
Documentation

Tables

A table is a set of questions asked of a set of documents. Rows are documents; columns are questions. Everything on this page is about the container — the questions themselves are the next page.

Creating one

Tables live in a workspace and are created from it. A new table has no columns, and its empty grid is where the presets are offered — a starter set of columns for a common document type, which you then edit to fit your documents.

Rows come from the workspace’s documents. You can add every document as a row, or add rows selectively by dragging files onto the add-row bar, and a row can point at a bundle rather than a single file.

Tables created in the app start in auto mode, meaning they extract each new document added to the workspace without anyone pressing Run. If you are still authoring columns, switch the table to manual first — see auto mode.

Tabs

A workspace’s tables appear as tabs above the grid, so several tables over the same documents stay one keystroke apart — a screening table and a deep-dive table over the same portfolio, for example. A table can be given an accent colour, which shows on its tab, and tabs can be hidden from the strip when there are more tables than you are currently working on.

Right-clicking a tab is where duplicating lives. Duplicating asks for a name and lets you choose what comes across: the settings, the columns, and the rows — including their existing values, citations and overrides. Copying rows with their answers costs nothing, because nothing is re-extracted; it is the fastest way to branch a finished table before changing a prompt.

Reading the grid

Each row has a numbered handle and a Documents cell listing its files; a row backed by several documents shows them indented under the first. Column headers carry an icon for the output type, so the shape of an answer is visible before you read it. A cell that has not run shows an em dash; one that is running shows an “Extracting…” badge.

Two display controls are worth knowing about, because both change what the table is useful for rather than only how it looks:

  • Hiding columns. Hidden columns are hidden from the view, not deleted — their answers survive and come back when you unhide them.
  • Cell wrap. Off, every row is one line and the table scans like a spreadsheet. On, long answers show in full. Quote-heavy tables want it on; wide screening tables want it off. Image columns follow it too — with wrap off their thumbnails shrink to about the height of a line of text, so a column of pictures does not dictate a taller row than its neighbours.

Narrowing a long table

A two-hundred-row table is not read, it is queried. The toolbar’s Filter builds a set of conditions, joined with AND, one per row of the builder — which invoices are over £5,000, which contracts expire before March, which cells came back with no answer at all. The operators you are offered come from the column’s output type, so a number column offers ranges and a category column offers its own options. Any column can also be sorted from its header.

Two things worth knowing. Filters read your overrides rather than the values underneath them, so what you filter matches what you are looking at. And they are not saved with the table — a filter is how you are reading it this afternoon, not a property of it.

The four settings tabs

TabWhat is in it
GeneralName (should be unique — the tab strip and the usage breakdown both identify a table by it), accent colour, the table’s copyable ID, and deleting the table.
ReviewRow trigger — automode or manual, which decides whether new documents are extracted without being asked. Document strategy — whether columns answer per document or compositionally across the whole row. Both need Manage on the workspace, because both are spending decisions. Output language — see below.
ColumnsAdding, editing, reordering and removing columns, and the preset picker. See columns.
ExportXLSX or CSV, with a row range and a choice of columns. See exporting.

Answering in another language

A table can be set to answer in a language other than English, from the Review tab. It is a table-level choice rather than a per-column one, and it governs the prose a column writes — a summarised clause, a description, an explanation.

What it deliberately does not change is the typed values. A date stays YYYY-MM-DD, a number stays a number, and a category stays exactly the option you wrote. That is not an oversight: a German table storing “31.12.2025” would look right and quietly stop sorting, filtering and grouping. The document’s own language is irrelevant either way — a French lease can be read into an English table without setting anything.

Changing the setting marks every column’s existing answers stale rather than rerunning them. Answers extracted in the old language are still correct, just no longer in the language the table asks for, so you decide when to spend the credits — see running and reruns.

Deleting a table

Deleting a table removes its columns and its answers. It does not touch the documents — those belong to the workspace, they were paid for at upload, and another table can still ask questions of them. This is the asymmetry worth internalising: tables are cheap and disposable, documents are the asset.