Notion for Lawyers: The Database Structures That Actually Hold Up

Notion is a genuinely good tool for running a legal practice, and it is also the tool I have seen the most beautiful, unusable legal systems built in. The gap between the two is almost never Notion's fault. It is database architecture, decided in the first hour of building, that either holds up against real matters or quietly stops being trusted within a few weeks.

Start from the primitives, not the template gallery

The template gallery temptation is real: a polished-looking case tracker with a kanban view and colour-coded tags looks finished before a single real matter has run through it. The actual test is not how it looks empty. It is whether the structure underneath models what a matter actually is, matter, actions, time, team, evidence, research, as separate, linked databases, rather than a single table with too many columns pretending to be six different things at once.

The core databases

Matters. One database, one row per matter, and this is the container everything else relates to. Client, matter type, jurisdiction, stage, and, critically, a relation property to every other database below rather than fields trying to hold everything inline. A matter page should be answerable in ten minutes by a stranger, which is only possible if the related actions, deadlines and documents are actually linked, not buried in a long-text field.

Actions. A separate database, related to Matters, holding the discrete steps that move a matter forward, each with a status, an owner and, ideally, a matter-type template so the same action sequence populates automatically for a new matter of a known type. This is the database most Notion builds skip entirely, folding "tasks" into a generic to-do list disconnected from the matter-type logic that should generate them.

Deadlines and time. Deadlines deserve their own tracked property set, not a due date buried in the actions table, because deadlines need their own view, a calendar rolled up across every open matter, surfaced before they become urgent. Duration data, how long actions of a given type actually take, is worth tracking as a separate rollup so the practice accumulates real pricing data over time rather than losing it the moment a matter closes.

Team. A relation, not a text field, connecting people to actions as doer and, where relevant, reviewer. Text fields holding a name look identical to a real relation until someone tries to filter "everything assigned to me across every open matter" and discovers the text field cannot do that reliably.

Evidence. The database most legal Notion builds get wrong, because it is tempting to treat documents as file attachments on the matter page rather than as first-class rows with their own metadata: source, date, what claim they support. Anchoring a specific claim in a draft to a specific evidence row, rather than a general folder of uploads, is what makes the anchoring discipline enforceable rather than aspirational.

Research. A separate knowledge base, related to matters but living beyond any single one of them, tagged by the question it actually answers rather than only by practice area, so a question answered for one matter is findable when the same question resurfaces in a different matter next year.

The mistake that breaks most Notion legal builds

Collapsing several of these into one table. A single "Matters" database with tasks as a checklist property, documents as file attachments, and deadlines as a date field looks simpler on day one and becomes unmanageable by month three, because none of those things can be filtered, rolled up or reported on independently once they are trapped inside another database's properties. The six primitives need to be six real databases, related to each other, even when that feels like more setup than the situation seems to warrant at first.

Views matter as much as the databases

A well-structured database with no purpose-built views is still hard to use day to day. A working legal Notion system needs, at minimum, a matter-type view filtered to a single practice area, a this-week deadline view rolled up across every open matter, and a my-actions view filtered to a single team member across everything currently assigned to them. Building these views once the databases are properly related takes an afternoon. Trying to retrofit them onto a collapsed, single-table structure later usually means rebuilding from the primitives up, which is the exact rework the paper-first step in any build is meant to avoid.

I built LexOS as the pre-wired version of this exact architecture, matters, actions, time, team, evidence and research as properly related databases, with the views already built, so a practice can install the structure that actually holds up instead of discovering the collapsed-table mistake three months into real use.