Users, Groups & Roles

Users

A user is an individual account within your workspace. Each user has a username, an email address, and a password. Users can be marked as active or inactive — inactive users cannot log in.

• Superadmin — superadmin users bypass all permission checks. The first user created during workspace registration is automatically a superadmin.
• Email verification — users receive a verification email after account creation. The platform tracks whether the address has been confirmed.
• Two-factor authentication — users can enable TOTP-based 2FA (compatible with apps like Google Authenticator or Authy). Once enabled, login requires both a password and a time-based one-time code.
• Preferences — each user can set their preferred currency and choose whether to receive email notifications.

Users support archiving — deactivated accounts can be restored rather than permanently removed.

Groups

Groups are collections of users. They serve as the bridge between users and roles: you assign roles to a group, then add users to that group. Every user in the group inherits the group's roles.

• Regular groups — manually created collections like "IT Managers", "Security Team", or "EU Admins".
• Personal groups — automatically created for each user (one user per group). Personal groups let you assign roles to an individual user without creating a shared group.

Roles

A role is a named set of permissions with an optional entity scope. Roles define what a group of users can do and, optionally, where they can do it.

• Name and description — human-readable identifiers (e.g. "IT Manager", "Read-Only Auditor").
• Permissions — create, read, update, and delete permissions per area. See Permissions for details.
• Entity scope — if an owning entity is set, the role only applies within that entity and its children. If no entity is set, the role is organisation-wide.

The Permission Chain

Access control flows through a clear chain:

1. Users belong to one or more groups.
2. Groups carry one or more roles.
3. Roles contain permissions (create, read, update, and delete per area) with an optional entity scope.

When Anzen checks whether a user can perform an action, it looks through all of the user's groups, then all roles on each group, for a matching permission. If any role grants the action (and its entity scope covers the target entity), access is allowed.

SSO / OIDC Support

Anzen supports Single Sign-On via OpenID Connect (OIDC). You can configure your workspace to authenticate users through an external identity provider such as:

• Keycloak
• Okta
• Azure Active Directory (Entra ID)
• Google Workspace

When OIDC is configured, users are redirected to your identity provider for authentication. After successful login, Anzen receives an authorization code, exchanges it for tokens, and creates or matches a local user account based on the email address in the ID token. Users authenticated via OIDC still follow the same group and role model for authorisation.