Users
Admin → Users is where access is granted. A person with no scope grant sees an empty product, which is by design: access is explicit.
| Role | Can do |
|---|---|
| Admin | Everything — providers, connectors, trust, certification, users, and all analyst features |
| User (analyst) | Chat, Registry, Data Explorer, scope boards, and metric requests |
Grant admin sparingly. It is the difference between someone who can query data and someone who can repoint the tenant at a different database.
Granting scopes
Section titled “Granting scopes”Each user has a set of granted scopes and one primary scope.
- Granted scopes determine what the Registry and boards they can reach.
- Primary scope is their default: their Home view, their Chat context, and the board they land on.
Set a primary scope as part of granting access. A user with three granted scopes and no primary will land on an empty Home — technically functional, confusing in practice.
Creating a user
Section titled “Creating a user”Admins create accounts directly, with a name, email, and role. The email is the identity: it must be unique, and under SSO it is the value your identity provider provisions against.
What people can request
Section titled “What people can request”Analysts can file metric requests from the Data Explorer. Admins see a pending queue and approve or reject each one. Approving creates a Registry metric; rejecting leaves a note explaining why, which the requester can read.
This is the intended path for the catalogue to grow: the person who found the number proposes it, the accountable person approves it.
Passwords
Section titled “Passwords”New users may be required to change their password on first sign-in. If your deployment uses SSO, local passwords are not the sign-in mechanism at all.