Docs / Authority / Authority Users

Authority Administration · Customer guide

Authority Users

The full register of every officer in your institution's reach — not just a list, but lifecycle state, account-linking state, effective access, and a proper role-change flow with a before/after diff.

Audience: Authority administrators Part of the Authority guide set

What this guide covers: the Authority Users register in full — lifecycle and account state, provisioning a brand-new officer, changing a role, and the Effective Access drawer.

What it doesn't cover: the account-provisioning wizard's basic shape, already introduced in Part 3 of the Command Centre overview — this guide goes one level deeper into the register that wizard feeds.

The register

The register

Found at Authority Administration → Authority Users. Columns: Name, Institution, Role, Lifecycle, Account state, Position, Jurisdiction count.

FieldValues
Lifecycleactive, suspended, ended
Account statelogin linked, invitation pending, invitation expired, invitation revoked, no account linked

These are kept as two separate fields deliberately — an officer can be a fully active directory entry with no linked login yet (for example, someone only named as a notice recipient), which is a different situation from an active login that's been suspended.

Provisioning

Provisioning a new user

Click Provision Authority User for the seven-step wizard: Identity → Institution → Role → Jurisdiction (optional) → Veterinary Contact link or creation (optional) → Invitation → Review.

Managing an officer

Role changes, suspension & effective access

  • Change role — shows exactly which scopes would be added and removed before you confirm, never a silent swap.
  • Suspend / Reactivate / End appointment — a reason is required for suspend and end; reactivate doesn't need one.
  • Effective Access drawer — opens per user and shows their real, combined access: their institution's own mandate kept clearly distinct from any jurisdiction assigned to them personally.
Every write action here is checked twice — against your route scope, and against a live capability flag fetched fresh from the server (things like "can invite users" or "can suspend users"). A stale permission in your own browser session can't unlock an action the server would actually refuse.