Roles and access

Who can do what in Tagaris. There are two kinds of authority: install-wide, held by the install owner, and per-organisation, held by that organisation's admins.

The roles

Role	Scope	What it can do
SuperAdmin	the install	Everything below, plus Application settings (licence, single sign-on, organisations and cross-org groups) and any organisation.
Admin	one organisation	Manage that organisation: its users and their roles, its settings, and all its data.
Editor	one organisation	Add and change register data (assets, people, locations and so on). Cannot manage users or settings.
Viewer	one organisation	Read-only.

Admin, Editor and Viewer are per-organisation. A person can hold a different role in each organisation they belong to.

SuperAdmin: the install owner

SuperAdmin is the person who owns the installation. It is set on the first-run setup account and is separate from the per-organisation roles. A SuperAdmin:

• Manages Application settings: the Tagaris licence, single sign-on, organisations, and cross-org groups. These are install-wide, so an ordinary organisation Admin does not see them.
• Can act in any organisation, with full Admin authority there.
• Is a local (password) login. This is deliberate: it is the break-glass account, so recovery never depends on single sign-on.

Keep SuperAdmins few, and protect their passwords. There is always at least one (the setup owner). On an upgrade that introduces this role, the earliest existing account is promoted so system settings stay reachable.

Application settings vs organisation settings

Settings are split into Organisation (any Admin) and Application (SuperAdmin only):

• Organisation: general, email, alerts, branding, users, integrations, data.
• Application: licence, single sign-on, organisations, groups, security, API, backups, access overview.

The split is enforced on the server, not merely hidden in the interface. The licence, single sign-on and add-organisation actions all require SuperAdmin.

Single sign-on and roles

When single sign-on is set up, each user's role comes from your directory through a required mapping (Entra App Roles or group IDs to Tagaris roles). Anyone without a mapped value gets the default role (Viewer or Editor, never Admin). Single sign-on can grant up to Admin, never SuperAdmin: SuperAdmin is the local install owner, set up in Tagaris, not in your directory. See Single sign-on for the setup steps.

Requiring single sign-on

With "Require single sign-on" on, password sign-in is blocked for everyone except SuperAdmins. Everyone else must use single sign-on. The SuperAdmin's local password login stays available as the break-glass account.

If single sign-on breaks

Sign in as the SuperAdmin with their password (the "Sign in as owner" link on the login screen), then fix or turn off single sign-on. If every SuperAdmin password is also lost, recovery is out of band through server access to the database; there is no standing recovery account beyond the owner.

Cross-org groups

For people who need the same access across several organisations, a SuperAdmin can create a cross-org group: a name, one role, and the organisations it covers. Add people to the group and they get that role in all of those organisations, without setting each one up by hand.

A person's effective role in an organisation is the higher of their direct role there and any group that covers it. So a group never takes access away; it only adds or raises it. Groups are managed under Settings, then Application, then Groups.

For developers

• The permission check is can(context, capability) in src/lib/permissions.ts, where context is { superAdmin, role }. Every gate should go through it rather than comparing roles inline. system.* capabilities need SuperAdmin; org.* and data.* are ranked by role (Admin > Editor > Viewer).
• getActiveContext() (src/lib/session.ts) resolves the active organisation, the user's effective role there, the superAdmin flag, and the list of organisations they can reach. canActive(capability) is the convenience wrapper.
• Effective role folds direct memberships and cross-org groups with mergeOrgAccess (src/lib/access.ts, highest role per organisation).
• Data model: User.isSuperAdmin, Membership (per-org role), and Group / GroupOrg / GroupMember (cross-org groups).
• Single sign-on enforcement is a better-auth before-hook in src/lib/auth.ts that blocks /sign-in/email for non-SuperAdmins when isSsoRequired() is true.