Client workspaces that never mix

TrackHeros keeps each client in its own workspace. Their meetings, transcripts, notes, action items, recordings and calendar stay there, and nothing from one client is visible from another. This page explains how that isolation is built, for anyone who takes several clients' meetings on Google Meet and Microsoft Teams and needs to be certain the notes never mix: a fractional CTO with three companies, a consultant with a portfolio, a developer with six accounts.

What does it do?

A workspace is a wall, not a folder. A folder is a way of sorting things that all live in one place, and anyone who has the place can open any folder. A workspace in TrackHeros is a boundary the software checks before it reads or writes anything.

In practice:

• Every meeting, transcript, summary, action item, recording, correction rule and bot setting belongs to exactly one client.
• Every screen inside a client shows that client only. There is no view inside Client A from which Client B's meetings, people or dates can be reached.
• The assistant that answers your questions reads only the client you are asking about.
• The few screens that show more than one client show labelled rows and can change nothing.
• Deleting one client leaves the others exactly as they were.

None of this is a setting. There is no toggle that turns isolation on, and none that turns it off. It is how the product is built.

How does it work?

Two layers, in a fixed order.

The application refuses unscoped queries

Every table that holds client data is scoped. Before a query on one of those tables runs, it has to name a client — the one whose workspace you are in, already verified as yours. A query that reaches the database without a client is not answered with everything; it is stopped with an error. That is the difference between a convention, where everyone remembers to filter, and a guard, where the code cannot forget. Forgetting shows up as a loud failure in development and testing, not as a quiet leak in production.

The database checks again

Underneath the application, Postgres row-level security carries a policy on every scoped table: a row is visible only when it belongs to the client the current database session is bound to. That binding lasts for one transaction and is cleared afterwards, so it cannot linger into the next request. If the application layer were ever bypassed — a raw query, a maintainer's shortcut, a bug nobody caught — the database still returns nothing that belongs to a different client. With no client bound at all, it returns no rows. It fails closed.

The two layers are set together. Entering a client's scope in the application binds the same client in the database in the same step, so they cannot drift apart.

What does the assistant see?

When you ask a question inside a client, the assistant retrieves from that client's meetings and nothing else. The passages it reads, the citations it returns, the correction rules it applies and the summary it can rewrite all come from the same workspace. It cannot be asked about Client B from inside Client A, because the retrieval that feeds it never sees Client B's rows. No prompt is clever enough to reach data the query never fetched. See search and ask across a client's meetings.

Which screens show more than one client?

Five, and they share one shape.

Surface	What it shows	Rule
Dashboard	Hours, activity, bot join rate and upcoming meetings, per client	Read-only
Meeting list and calendar	Every meeting, labelled by client	Read-only
Action items	Every open item, with its client and its meeting	Read-only from here; edit inside the client
Search	Keyword and semantic matches, each labelled with its client	Rows, never an answer
Global chat	A read-only assistant mode over your own history	Every fact labelled; nothing blended; nothing changed

The list of clients these screens draw from is the list you own, verified before anything is read. Each row carries its client. Nothing is merged: a search result is a line from one client's meeting, an action item is one client's item, and a global chat answer is a set of facts each labelled with where it came from. If a question would need two clients' facts woven into one narrative, the global chat does not weave them. And nothing can be edited from global mode. To change a summary, resolve an action item or add a rule, you enter the client, where the change is scoped.

This is the one deliberate exception to "one client at a time", and it is narrow: your own data, laid over your own clients, with the owner printed on every row.

What happens when a client is archived or deleted?

Archiving a client removes it from every cross-client view: dashboard, meeting list and calendar, action items, search and global chat. Its data stays, and you can open the client directly, but it stops appearing wherever "all my clients" is implied.

Deleting a client removes its data: the database rows, the stored recordings and transcripts, and the copy held by the meeting-bot service. The other clients are untouched, because nothing of theirs was ever inside the deleted workspace. The same cascade runs for your whole account if you delete that. What we promise about your data, in four sentences, is on the privacy section of the homepage.

Why does this matter more than it sounds?

Most meeting tools assume one company, one workspace, one team. Sharing is the feature; separation is an afterthought. For someone who works with several clients, the wrong feature is the dangerous one. A mixed-up note in front of a client is not a bug you apologise for; it is the end of the trust that got you the work. Isolation is the reason TrackHeros exists, which is why it lives in the query layer rather than in a settings page. It is the same reason each Google account can belong to only one client — see multiple Google accounts — and why the fractional CTO page starts with it.