Running a practice: who owns each client, what is due, and what you are waiting for

Every other screen in the product belongs to one client: their ledger, their invoices, their return. The practice board alone belongs to the firm. The two client boards already answered "how do the numbers look across my clients?" — cash, receivables and payables, drafts still unposted, the auditor's flags, each client's tax position on its own country's cadence. But a practice is not run on numbers alone. It is run on three questions, and none of them had an answer on any screen.

The three questions a practice runs on

1. 1Who is responsible for this client? Membership says who may open the books, and five people legitimately can. It never said who owns the relationship and who gets asked — so "which of my clients has nobody on it", the question behind every missed deadline in a growing practice, had no answer anywhere.
2. 2What is due, beyond the statutory dates? VAT deadlines are derived from each country's settings and payroll dates from the payroll module. The trade licence renewal, the year-end pack, and "management accounts by the 10th" lived in one person's calendar.
3. 3What are we waiting for? Half of an accountant's open work is not work at all — it is a question sent to the client three weeks ago and never answered. Nothing tracked it, so it was chased from memory or not at all.

Three roles, and one seat per role

An assignment in Fatouraty is keyed on the client and the role together, not on the client and the person. Three roles: the manager who owns the relationship, the preparer who keeps the books, and the reviewer who signs them off. Assigning a second preparer replaces the first rather than joining them, because two preparers on one set of books is the same as none: each assumes the other did it.

The assignee must already be a member of that client's workspace. A name on a board whose owner cannot open the books is a responsibility that cannot be discharged — worse than an empty seat, because it looks covered. Two rules protect that, both learned the hard way. Changing an assignment needs admin rights, the same bar that governs membership changes; gated on write access alone it was strictly weaker than the thing it depends on, and any bookkeeper could take the manager off a client and put themselves there instead.

The second is that removing a member clears their assignments and takes their name off their open work, in the same transaction as the membership delete. Without it the back door produces exactly the state the assignment path refuses to create: a board still naming a departed colleague as the preparer of books they can no longer reach. Their tasks are unassigned rather than deleted — the bank reconciliation still needs doing, and unassigned work on a client falls to that client's preparer, whereas work still carrying the name of someone who has left is on nobody's list.

What can be derived stays derived; the rest gets written down

This is the rule that decides what becomes a task at all. VAT deadlines come from the tax board on each client's own country cadence, and payroll dates from the payroll module, and neither is copied into a task: a copy of a deadline is a deadline that goes stale, still displayed after the thing it was copied from has changed. So the task list holds only what the system cannot derive — a licence renewal, a year-end pack, a stock-count visit, management accounts on the day you promised them.

Repeating tasks do not drift. The original day of the month is carried forward rather than computed from the previous occurrence — the same mechanism recurring invoices use, and for the same reason: rolling from the previous one makes the 31st fall to the 28th in February and stay there forever, so "management accounts at month end" silently becomes "on the 28th" after a single February, and nothing puts it back. The acceptance suite walks January to April and asserts 31, then 28, then 31, then 30.

Completing a repeating task creates the next occurrence rather than moving the same row forward. A recurring commitment whose only record is its next due date cannot answer "did we send the September accounts?", and that is the question that actually gets asked when one gets asked.

"Mine" means assigned to me, or unassigned on a client whose books I prepare. A task with no assignee on a client that does have one is not unowned, and showing it as somebody else's problem is how it stays undone. That filter runs inside the database rather than over the fetched page — applied afterwards, the row cap is spent on other people's work first, so the bigger the firm the more of your own list silently goes missing.

A task's title and detail are encrypted at the field level, because a real title reads like "chase the client about the disputed forty thousand" — a named third party and a figure beside it, written by someone who assumed nobody else would read them. The same items also appear on the client's own dashboard under "work on this client", because the accountant already inside a client's books is the one about to do the work, and a deadline they have to go somewhere else to find is a deadline they miss.

A query is a debt they owe, not one you owe

A task is work we owe. A query is an answer they owe. Merging the two into one list costs the accountant the single fact they need on a Monday morning: which of these is blocked on somebody else, and for how long. So every query carries an age in days, and that is the number that gets it chased: amber while it is under two weeks, red past fourteen days.

A query stays on the board after it is answered and leaves only when somebody closes it. The answer arriving is not the same event as the work being done: the photo of the receipt came back, and you still have to post it. A query can also name the bill it is about, through the same convention documents are filed with — which is why a bill carries an "ask the client" box directly under its attachments strip. The moment anyone notices a missing receipt is while looking at the bill, and a question that has to be typed somewhere else gets sent from memory later, or not at all.

Reads cross clients; writes never do

A practice in this product is not a table in the database. It is one user with many client workspaces — which is how billing, tenancy and both existing boards already model a firm. So everything here hangs off the workspace id like every other row, and "the practice's view" is the union across the workspaces the user belongs to. That preserves a property worth more than a separate table's convenience: a client's work items are reachable only through a membership in that client's workspace. Lose access to a client and you lose their tasks and queries with it, automatically, with no second list to remember to update.

The three practice boards are the only reads in the product that take a user rather than a tenant context: they resolve the workspaces that user belongs to and query those ids in one statement. The membership join is the authorization — a workspace the user is not in cannot enter the id list at all, so there is no downstream filter to forget. Naming one client narrows that list and cannot widen it: asking for someone else's client returns nothing, not their work.

Writes take a tenant context resolved for the client being written to, exactly like the rest of the product; there is no cross-workspace write path. Forms inside a client's page post the workspace id pinned into that page rather than the active workspace — the active workspace is one shared row across tabs, and an action that reads it at execution time can file a question against the wrong client after a switch made in another tab.

What this does not do today

This is not a timesheet, not fee billing, and not a document-approval flow. It is three questions and three answers. Assignments are edited on the client whose books are currently open, because assignment needs that specific client's member list, and offering another team's roster would produce assignments the write path is right to refuse. And each client workspace carries its own subscription, as it does everywhere else in the product — the isolation here is not a display choice, it is what the board itself is built on.