Who can see which users
To administer access, you have to be able to see the people who have access — to grant them more, revoke them, or add a colleague. This page is about that: which people an administrator can find and manage. It is a different question from who can see the data, and it travels along a different axis.
- Data visibility flows up the tree by inheritance.
- People visibility is bounded by the organization, and within an organization is flat by default.
Keeping these separate is what lets colleagues in data-isolated scopes still find and help each other, while people in different companies stay invisible to one another.
Visibility is derived from grants
A person is not "assigned to" or "listed on" a scope. A person is simply someone holding a set of grants. From those grants, visibility follows automatically:
- Any grant makes a person visible where they hold it — Reader, Editor, Curator, Arbiter, Operator, Admin, Owner, or Billing. Billing is included on purpose: a finance contact attached to a scope must be findable there, so that an administrator who later wants to give them data access can pick them from the scope's people rather than re-inviting them from scratch. (Being visible still confers no data access — the two are separate questions.)
- People who haven't logged in yet are visible too, marked pending. When you give access to someone by name before their first sign-in, they appear right away so you can manage them; the pending mark clears itself the first time they log in.
Nothing about visibility is stored by hand — it is always computed from who holds what, so it can never drift out of step with actual access.
The organization is the hard boundary
A person's visibility never crosses an organization boundary, in either direction. This is the confidentiality seal for people, and it is absolute: people in different organizations cannot see each other even when one organization is nested inside another's subtree.
Within a single organization, the default is flat — everyone with a grant anywhere in the organization is visible to everyone else in it. That is usually what you want: colleagues can find and administer one another across internal scope divisions.
Two optional limits within an organization
Sometimes a scope wants to keep its own people less visible, even to colleagues in the same organization. A scope can set either or both of two independent limits on the people who hold grants at it:
| Limit | Effect |
|---|---|
| (none — the default) | The scope's people are visible to everyone in the organization. |
| Restrict upward | The scope's people become visible only to its own sub-scopes — parent and sibling scopes can no longer see them. |
| Restrict downward | The scope's people stay visible to parents and siblings, but its own sub-scopes can no longer see them. |
| Both | The scope's people are visible only to the scope's own administrators — a fully private scope inside the organization. |
These limits only ever narrow visibility, and only within the organization — they can never widen it past the organization wall. Setting one is a confidentiality-relevant change and is recorded in the audit trail.
What "seeing a person" reveals
When you can see a person, you see their identity (their name and email) and only the grants they hold within your own visibility — never their access anywhere else.
This is the guarantee that keeps organizations sealed even when the same individual works across several. If a consultant has access in your scope and also, separately, in another company's, you see their grant in your scope and nothing about the other. "Someone from elsewhere has access here" is visible; "where else they have access" is not.
This rule binds every place a person could be revealed — user lists, the members of a group, the subject of a grant. Visibility is a confidentiality boundary, not a display convenience, so no screen or query exposes a person you are not entitled to see.