My Top 10 Notion Databases Every Law Firm Should Have

Every failed Notion build I have inherited from a firm has the same shape: a scatter of standalone pages, each one someone's good idea on a slow afternoon, none of them talking to each other. What actually holds up is a small set of relational databases, linked deliberately, so that opening a matter surfaces its related tasks, documents, and time entries automatically rather than requiring anyone to remember where they filed each piece. Here are the ten I build into almost every firm's workspace, and the relation each one needs to actually earn its place.

1. The Matters database

This is the spine everything else relates back to. Every other database on this list should have a relation property pointing at a row in Matters, not a text field with the client's name typed in freehand. Client, matter type, status, opening date, responsible attorney: keep the properties few and structural, because this database's job is to be the hub, not to hold the detail.

2. The Clients database

Separate from Matters, because one client frequently has more than one matter, and collapsing the two forces you to duplicate contact information every time a returning client opens a new file. A Clients database with a relation to Matters lets you see a client's full history in one view, which matters enormously the first time a returning client calls and nobody who answers the phone was on the original matter.

3. The Deadlines database

Not a field inside the Matters database, a separate relational database of its own. A deadline needs its own row because it has its own properties: a due date, a responsible person, a type, a status, and often a calculated warning window before it, and cramming that into a single date field on the matter loses all of that structure. Relate every deadline back to its matter and filter this database by a rolling view of what is due this week across every open file at once.

4. The Documents database

Every document should be a row, not just a file dropped into a folder, because a row can carry a document type, a version number, a status, and a relation to the matter and even the specific task that produced it. This is the single biggest upgrade over a plain file system: you can filter by document type across every open matter, which is exactly what you need when a new regulation requires checking whether a specific clause is present in every active contract.

5. The Tasks database

Related to Matters, and ideally also related to a specific stage in that matter's lifecycle, so a task is not just floating, it is anchored to where in the process it belongs. A Tasks database that can be filtered by assignee, by matter, and by due date simultaneously replaces most of what firms are still tracking in someone's personal notebook.

6. The Time Entries database

Even in a flat-fee practice, a time entries database is worth keeping, because it is the only reliable data you will ever have on how long work actually takes, which is exactly what flat-fee pricing needs to be set correctly. Relate every entry to a matter and, where relevant, a task, so you can eventually answer the question every partner eventually asks: which matter types are actually profitable at the price we are charging.

7. The Intake Pipeline database

Separate from Matters entirely, because most inquiries never become matters, and mixing the two pollutes your matter data with dead leads. A pipeline database with stages, inquiry, screened, engaged, declined, gives you an honest view of your intake funnel, and it is the database most firms are missing entirely, which is a large part of why intake is where firms leak the most revenue.

8. The Referral Sources database

Related to both Clients and Intake, this database is where you finally get an honest answer to "where do our best clients actually come from," instead of a guess based on whoever a partner happened to have lunch with recently. Track the source, the relationship owner, and every matter that traces back to it, and the pattern in the data usually surprises people who thought they already knew the answer.

9. The Vendor and Expert database

Every practice accumulates a working list of experts, process servers, court reporters and consultants, and it almost always lives in someone's contacts app rather than anywhere the firm can search. A relational database here, tagged by specialty and related to the matters they have worked on, turns "who was that expert witness we used two years ago on the similar case" from a memory exercise into a filtered view.

10. The Knowledge Base database

Every practice generates research, memos and precedent language worth reusing, and without a structured place to put it, that work gets buried in old email threads and closed matter files, effectively lost. A Knowledge Base database, tagged by topic and related back to the matter that produced it, is what turns one-off research into something that compounds instead of getting rebuilt from scratch on every similar matter.

Why the relations matter more than the databases

None of these ten databases does much on its own. A standalone Deadlines database is barely better than a spreadsheet. The value shows up entirely in the relations between them: opening a matter and seeing its deadlines, documents, tasks and time entries all surface automatically, without anyone having to remember to look in four different places. That is the actual difference between a Notion workspace that looks organised in a screenshot and one that a firm still trusts eighteen months later, after real matters have been run through it and the structure has been tested by volume, not just by a demo.