User provisioning
How Viewer decides whether someone who signs in through your IdP gets an account, and what access they start with — invite-only vs. just-in-time (JIT).
Provisioning decides whether a person who signs in through your IdP gets a Viewer account, and what access they start with. The two modes differ only in what happens when someone signs in whose email Viewer doesn't already recognize:
| Invite-only (default) | JIT (just-in-time) | |
|---|---|---|
| A new person signs in | Rejected unless an admin already created their account in Viewer. | A Viewer account is created automatically, starting with no access until you grant a role. |
| When to use | The safe default — use it whenever you want explicit control over who has an account. | Use when your IdP is the source of truth for who should have access and you don't want to pre-create every user. |
In both modes, if the signed-in email already matches a Viewer account, it links to that account. They differ only for an unrecognized email: invite-only turns it away, JIT creates a no-access account for you to grant a role to. Either way, nobody gets data access automatically — a new account starts in NO_ACCESS until you assign a role (see Roles & permissions).
Turning on JIT
JIT can be enabled once at least one SSO connection is enabled — there has to be an identity provider to provision from. Until then the toggle stays disabled and the screen says so.
- Go to Admin → Identity & Provisioning (
/dashboard/admin/identity). - In the User Provisioning section, read the current mode badge (Invite-only / JIT).
- Toggle to JIT and confirm.
Reverting JIT back to invite-only is always allowed.
The review queue (JIT only)
When JIT is on, the Identity & Provisioning screen shows a Provisioning Review list of accounts that were auto-created — when they first signed in, when they last signed in, and what roles they hold — so you can grant each new arrival the right role.
Sticky-suspend
If an administrator suspends a user (sets them to NO_ACCESS), that suspension holds even if the user signs in again through the IdP — group→role mapping will not silently re-grant access. The suspension is only lifted when an admin assigns the user a data role (any role other than NO_ACCESS). This prevents a removed user from regaining access just by re-authenticating.
Access requests
A user in the no-access state sees a landing page explaining they need access, with your admin contact (if configured) and a Request access button. When they request, the request is recorded, your administrators are notified by email, and the user's row on Admin → Users shows an "Access requested" badge with the date.