Use case · consultants and partners
One person. Four clients. Four separate estates.
This is the case most access systems handle worst, and it is worth explaining because the fix is structural rather than clever. Somebody who works across several clients is the person most likely to be handed a shared credential, and the person for whom that is least acceptable.
The usual shape is that identity and data scope are the same lookup: this email belongs to that client, therefore that database. A person on two clients then has two answers to a single-answer question, so the system either refuses them or picks one. Both are bad, and the second is worse because it is silent.
What breaks, and how
The three usual workarounds, and what each one costs.
None of these is anybody's stupidity. They are what you do when the model underneath makes belonging to two places an error state.
| The workaround | What it solves | What it costs |
|---|---|---|
| A second account per client | Each login is unambiguous again. | Joiners and leavers now run four times, in four places, and the one nobody remembers is the one that stays live after somebody leaves. |
| A shared service credential | Everything works immediately. | Every answer is attributable to the credential rather than to a person, so the audit trail answers "the connector read it" and nothing else. Taking it back changes it for everyone. |
| A pasted long-lived token | It gets the consultant working today. | Whoever holds it is that person until it expires, and its most likely resting place is a repository or a config file on a laptop. |
All three are the same mistake with different ergonomics: identity and data scope collapsed into one lookup. Separating them is the entire design here.
How it works instead
One person, several grants, one at a time.
A person is one row, platform-wide, keyed by a verified work email. What they may reach is a separate row per client estate. Holding four is normal and governed rather than an error, and each request resolves exactly one of them.
| Client estate | Environment | What they hold | Reached via |
|---|---|---|---|
| Estate one | Test | planning read | its own hostname |
| Estate one | Prod | planning read | its own hostname |
| Estate two | Test | planning read, tasks | its own hostname |
| Estate three | Test | handbook only | its own hostname |
Each estate is its own address, which is not branding. A connector that carried the client in a URL path lost it after the sign-in round trip on an earlier product, so the client name is part of the address itself. That is why a multi-client person is unambiguous here and was not there.
What a client sees
Your client can read the trail for their own estate.
This is the part that makes the arrangement sellable to the client rather than merely convenient for the consultant. They are not being asked to trust that the separation holds.
Theirs to see
- Every call against their estate, allowed and refused, under the consultant's own name.
- Their own export, so the record leaves with them and does not have to be requested.
- Their own switch. A client administrator turns capabilities on and off for their estate without involving us.
Never theirs to see
- That another estate exists. A refusal never teaches anybody about another client, including whether one is there.
- Another client's data, ever. A customer organization may only reach its own projects, checked where access is created and again where it is used.
- Anything cached from another estate. Caches are keyed per estate and re-checked on read rather than trusted.
Before this is real for you
What has to be true first.
The multi-client design is the oldest and best-tested part of the platform. The gaps here are about proving it with real people rather than about whether the model is right.
Each client's directory has to allow it
Signing in with a work account means that client's identity provider permitting a third-party application. At enterprise size, assume an admin consent process, and test it with one account before promising anyone a date.
A second client gets its own address
Already the case, and worth stating: each estate gets its own hostname before its people sign in, so the estate is never inferred from who is asking.
No client administrator has signed in yet
The console exists, both halves of it, and no client's own administrator has used it. If you are the first, that path gets walked with you rather than handed over.
The isolation rules this rests on are written out for a reviewer on the security model page, including the parts not yet proven.
If you deliver for several clients, start here.
It is the case that costs most to retrofit and least to get right at the beginning, because it decides how identity and access are separated before anybody has built a habit around the wrong answer.