Users & Roles

User Management has three tabs: Users, Teams, and Roles. Each is gated separately, so you may see one or two rather than all three: Users needs users:view, Teams needs users:read, and Roles needs users:roles.

The permission model itself, the catalogue, and the built-in roles are covered in Tenants & RBAC. This page is the operational side.

The stat strip

Active Users, MFA Enabled, Total Roles, and Pending Invitations.

Read MFA Enabled against Active Users as a ratio rather than a count. It is the fastest posture check available on this page, and a gap there is a finding about your own tenant of exactly the kind Argus raises about your cloud.

Pending Invitations is the other one to watch. A pile of stale pending invites is both untidy and a small standing risk, since each one is an unredeemed path into your tenant.

The account lifecycle

Status	Meaning
Pending	Invited, has not accepted yet
Active	In use
Inactive	Disabled. Cannot sign in, and holds no permissions

Pending and inactive rows render dimmed. A pending row shows when it was invited rather than a join date and has no last-active value, because there is nothing to report yet. A disabled row shows when it was disabled and, where known, who disabled it.

Disabling is immediate and total, and is the reversible option

An inactive user holds no permissions at all, regardless of the roles still attached. The permission check fails on the inactive flag before it ever looks at roles.

That makes Disable the correct response to someone leaving, a suspected compromise, or a contractor between engagements. It takes effect at once, keeps the account’s history and audit trail intact, and can be undone. Deleting is the destructive option and there is rarely a reason to reach for it first.

Inviting a user

Invite by email and assign a role. The invitation is emailed and the account appears immediately as Pending.

One rule to know before you plan your onboarding: only a tenant owner can invite someone into an admin-level role. If you hold users:invite without being the owner, you can bring people in at any non-admin level, and admin appointments route to the owner.

Per-user actions

The available actions depend on the account’s status.

On a pending invitation:

Action	Effect
Resend Invitation	Sends the email again
Edit Role	Changes the role they will receive on acceptance
Revoke Invitation	Cancels it

On an active user:

Action	Effect
Edit User	Name and details
Reset Password	Starts the password reset flow
Reset MFA	Clears their MFA enrolment so they can re-enrol
Change Role	Subject to the escalation guards
Disable User	Immediate, reversible
Delete User	Permanent

On an inactive user: Enable, or Delete.

Two guardrails apply throughout:

• You cannot delete your own account. Rejected outright, so nobody locks themselves out of a tenant they administer.
• Role changes are checked against your own permissions, not just against the role’s level. See the escalation guards in Tenants & RBAC.

Reset MFA deserves a moment’s thought. It clears the second factor on an account, so a caller who can convince you to do it has removed a security control. Verify who you are talking to out of band first. The action is audited with you as the actor.

Reading the users table

Column	Notes
User	Name and email
Role	Assigned roles
Status	Pending, Active, or Inactive, with an icon
Invited By	Who brought them in
Date	Invited, joined, or disabled, depending on status
Last Active	Derived from live sessions, not from last login

Last Active is session-derived, which makes it a better dormancy signal than a login timestamp: it reflects real use rather than the last time someone authenticated. Sort by it to find accounts worth disabling.

Remember that this list is filtered by your own standing. Non-owners never see tenant owners, and users without an admin role never see admin users, so a colleague’s list can legitimately be shorter than yours.

The Roles tab

Lists every role with its type and how many users hold it. System roles are labelled as such and are read-only.

Action	Available on
Edit	Custom roles only
Clone	Any role, including system roles
Delete	Custom roles with zero users assigned

Clone a system role rather than building from scratch. You start from a coherent, tested permission set instead of assembling one from a long checkbox list, where the easiest mistake is omitting a :view permission and producing a role whose holder cannot see the page their other permissions apply to.

The role editor groups permissions by module and flags dangerous ones inline, so you can see at a glance whether a role you are assembling is more powerful than you intended.

Requiring zero assignees before deletion means removing a role can never silently strip access from someone: reassign first, then delete.

The Teams tab

Teams group users so ownership can sit with a group rather than a person. Each team has a name, a description, and members, shown as pills with an overflow count.

Alerts, incidents, policies, and policy violations can all be assigned to a team. For anything carrying an SLA, prefer a team: work assigned to an individual stalls when that individual is unavailable, and the clock does not stop. See Alerts & Incidents.

Everything here is audited

Every action on this page is recorded, and role changes are logged individually per role, as separate assign and unassign events rather than one lumped “user updated”. So the audit log answers “who gave this person remediation:execute, and when” precisely. See Audit Log.