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.
One consultant with four clients is four trust boundaries. Wearing one login.
A person on two clients has two answers to a single-answer question.
The usual shape is that identity and data scope are the same lookup: this email belongs to that client, therefore that database. 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 |
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. What follows is the short list of things to settle in your own estate before the first person signs in.
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.
Your administrators get walked through it
The console has two halves, one for us and one for your own administrator, and the first sign-in is done with you rather than handed over as a document. After that, grants and revocations are theirs to make.
The isolation rules this rests on are written out for a reviewer on the security model page, in full and in checkable terms.