The data model behind a law firm: the matter as the only key, time captured live not reconstructed, calendar events bound to a matter, documents with a source.
Key takeaways
- The matter id is the firm's only key. A calendar event, time entry or document without one is orphaned data and appears in no report.
- Time captured live and time reconstructed at month end are two different kinds of data. Store a field that tells them apart.
- An access flag on a matter is a technical access-control mechanism. It enforces who sees a record, and nothing beyond that.
- Every date in the system is a date somebody typed. The system computes no deadlines and draws no conclusion from them.
- The only meaningful metric is the share of records created already linked to a matter.
A law firm's system stores four objects: the matter, the time entry, the calendar event and the document. Everything else is a view over them. Automation binds the last three to a matter id at the moment they are created rather than at month end. It records what happened and when, and decides nothing.
This is a technical description of data and workflow, not legal advice and not guidance on running a case.
The four objects the system actually stores
Each has its own key and a defined relationship to the matter:
- Matter.
matter_idis the primary key, alongside client, responsible lawyer, opening date, status and billing arrangement. The matter's name is not a key, because names change. - Time entry.
entry_id, carryingmatter_id, the actor, a start timestamp, duration in minutes, a narrative, a billable flag and the capture source. - Calendar event. A stable iCalendar
UID, a nullablematter_id, attendees, and theSEQUENCEandRECURRENCE-IDproperties that separate an updated event from a single moved occurrence in a series. - Document.
doc_id,matter_id, a received timestamp, a source channel, the original filename and a content hash that catches duplicates.
The relationships are simple: one matter has many of each, and each of the others belongs to at most one matter. The moment a record is allowed to exist without a matter, you have created a fifth category that nobody closes.
Why is a timesheet written at month end different data from one captured live?
Because the capture source determines the accuracy of the number, and without a source field you cannot tell which you are reading. Three sources produce three qualities:
- A live timer. Real start and stop timestamps. The duration is not rounded and the narrative was written while the work was happening.
- Manual entry at the end of the day. Durations are almost always rounded to the quarter hour, and narratives get shorter.
- Derived from a calendar event. Exact against the schedule, but it measures what was planned rather than what occurred.
Storing source on every entry is the difference between a report you can explain and a report you argue about. The same separation of planned from actual runs through tracking studio hours, milestones and budget.
Which matter fields carry weight, and which are display only?
| Field | Type | Why it exists |
|---|---|---|
matter_id | Stable identifier | The key every other record points at |
client_id | Reference | Separates client from matter, because one client can hold several |
status | Closed value set | Open, on hold, closed. Free text here breaks every report |
responsible_user | Reference | One owner, even when a whole team works the file |
billing_arrangement | Closed value set | Hourly, fixed fee, or non-billable |
opened_at | Date | An opening date that was typed, never one that was computed |
access_flag | Flag | Whether the matter is restricted to a defined user group |
matter_name | Free text | Display only, never a key |
The last row breaks first. Firms identify a matter by a string such as a client name plus a year, then somebody fixes a typo and two years of entries detach from each other.
What an access flag does, and what it does not decide
access_flag is a technical mechanism that narrows the set of users who can see a record. It has three measurable effects:
- It filters the matter out of lists, search and reports for anyone not on the permission list.
- It applies the same filter to the calendar events, time entries and documents linked to that matter, because otherwise the restriction leaks through reporting.
- It writes to an audit log: who changed it, when, and from what to what.
What it does not do: it does not decide who should be restricted, and it does not substitute for a human decision on that question. The system enforces a list somebody entered.
Where the model breaks in practice
- A calendar event with no matter. The meeting was booked from a phone, never passed through the system, and its time appears in no matter report.
- A single moved occurrence in a series. Without
RECURRENCE-IDthe update lands on the whole series, and three unrelated matters shift by an hour with nobody asking. - A document arriving over chat. It lives in the recipient's phone with no
doc_id, no received timestamp and no source channel. - Editing a locked entry. Somebody amends an entry in a closed month and a report already sent to the client stops reconciling. A correction should be a new record with a reference, not an in-place edit.
- The same client twice. A second
client_idis opened against the same company number, and every client-level report shows half the picture. - An empty narrative. The entry exists but has no content, and two months later nobody can approve it.
The three reports the model has to be able to produce
A data model is judged by which reports it can produce with no extra typing. Three of them cover almost all day-to-day need in a firm, and all three rest on the same matter id:
- Hours by matter and period, broken down by actor and by billable flag, so you can see what was done and what is chargeable.
- Records not linked to a matter, split across calendar events, time entries and documents. This is the only report that measures the health of the model itself.
- Movement on a matter in the last month: when it was last touched, by whom, and in what kind of record. A matter untouched for six weeks is not necessarily a problem, but it should be visible.
A fourth report, a record-level change log, is not operational but infrastructural: without it you cannot explain why a number in an already-issued report changed.
What to settle before you build
- Where
matter_idcomes from, and who is allowed to open a new matter. - A closed value set for
statusand for billing arrangements, including what happens to entries when a matter closes. - A locking rule: from what date a month is closed to edits, and what a correction after that looks like.
- A single intake channel for documents, so every document carries a recorded source. Signed approvals keep the same evidence logic as a digital signature evidence trail.
- Who owns orphaned records, and what happens to them after a week.
Sources
Frequently asked questions
Can the system calculate case deadlines on its own?
No, and nothing here recommends that it should. The system stores dates somebody entered and displays them. Working out what a date means in a case is professional judgement; the software's only role is to surface what was recorded, to the person responsible, in time.
What is the difference between a client and a matter in the data model?
The client is the entity identified by a company or personal ID number that carries billing details. A matter is one unit of work with its own responsible lawyer, status and billing arrangement. One client can hold several matters at once, so merging the two breaks every separate report.
Why store a source field on every time entry?
Because it explains the quality of the number. A live timer, an end-of-day retype and a calendar-derived entry have very different accuracy. Without the field a timesheet looks uniform, and any discussion of it becomes an argument about memory instead of about data.
What do you do with a calendar event that has no matter?
Leave it visible in a dedicated queue with an owner, and never attach it to a matter by guesswork. Legitimate internal events stay matter-less permanently, so you need a status meaning reviewed. Auto-assigning by attendee name puts hours on the wrong file.
Keep reading
Related service
Business Automation
I build custom automations that remove repetitive work end to end.
About the author
Yehonatan Saadia
Freelance automation, web & MVP developer
I'm Yehonatan Saadia, a senior developer who builds business automation, custom websites, and MVPs for small and mid-sized companies across the US, Europe, and Israel. These guides come from real client work, not theory.
Work with meHave a project like this?
Tell me what you're trying to automate or build. I reply within 24 business hours with a few targeted questions, then we walk through it on a free 30-minute call, with no commitment. You come away with a scope, a timeline and a fixed price - or a straight answer that it isn't worth building.