Permissions (RBAC)

How Permissions Work

Each role in Anzen carries a set of permissions that control what members of that role can do. Permissions are defined per area of the platform - for example, tickets, controls, configuration items, or entities - and for each area you can grant or deny four actions: create, read, update, and delete.

When you set up a role, you pick which areas the role should have access to and which actions are allowed in each area. Any area or action not explicitly granted is denied by default. For instance, you might create a "Read-Only Auditor" role that grants read access to tickets, controls, and issues but does not allow creating, updating, or deleting anything.

Entity Scoping

Every role has an optional owning entity. This controls where the role's permissions apply:

• Organisation-wide - if no entity is set, the role applies everywhere in the workspace.
• Entity-scoped - if an entity is set, the role only applies within that entity and all of its children.

Hierarchy Inheritance

When checking whether a user can act on a resource belonging to a specific entity, Anzen walks up the entity tree from the target entity to the root. If any of the user's roles are scoped to any ancestor in that chain, the permission is granted.

For example, if a role is scoped to "EU Office" and a user tries to edit a ticket belonging to "EU Engineering" (a child of "EU Office"), the permission check succeeds because "EU Office" is an ancestor of "EU Engineering".

Built-in Roles

Every new workspace ships with eight built-in roles, seeded automatically when the workspace is created. They give you a governable workspace on day one without hand-building a single role. Each built-in role carries a Built-in badge and a lock icon, and is frozen: it cannot be edited or deleted. To customise one, use Duplicate to copy it into a normal, editable role and adjust the copy.

• Full Administrator - everything, including billing. The broadest built-in role.
• Administrator (no billing) - everything except billing. Day-to-day platform administration without access to invoices or plan changes.
• GRC Consultant - controls, control tests, risk, issues, vendors, and the knowledge base.
• ITSM Support - tickets and issues in full (including internal comments), plus read access to the CMDB.
• Auditor (read-only) - read access across the whole platform, with no ability to create, update, or delete.
• Risk Manager - the risk register and issues.
• CMDB / Asset Manager - configuration items, vendors, types, business processes, and cloud connectors.
• Portal User - the default end-user role: tickets plus limited read access to issues and controls. Users who self-register via the Service Portal receive this role by default.

A built-in role is how you grant broad access without making someone a superadmin. A superadmin is separate and bypasses every permission check (see below); a built-in role still works within the permission system, so its access stays auditable and scopable.

Bulk Editing the Permission Matrix

When you edit a custom role, permissions are laid out as a grid: one row per area (model) and one column per action (create, read, update, delete, and the special actions). To set many cells at once, each row and each column carries a master toggle.

The row toggle sets every action for that one area. The column toggle sets that one action across every area that supports it. Only valid area/action combinations are ever toggled - actions that do not apply to an area (for example, a special action on an area that does not offer it) are left untouched.

A master toggle shows an indeterminate state when only some of the cells it controls are set, so you can see at a glance where a row or column is partially granted.

Superadmin

Superadmin users bypass all permission checks entirely. Every action is allowed regardless of roles, groups, or entity scope. The first user created during workspace registration is automatically a superadmin. Additional superadmins can be designated by existing superadmins.

Areas Covered by Permissions

The following areas are subject to permission checks:

Special Permissions

Some permissions use non-CRUD actions:

Internal Comments and the Requestor Role

The comment_internal action unlocks two things together: seeing internal comments in a ticket or issue timeline, and posting comments marked internal. Grant it to staff roles (for example a service desk role that already holds Ticket or Issue update) by adding the Ticket and Issue areas to the role and enabling the comment_internal action, scoped to the relevant entity or organisation-wide. The default Portal User role, and any role used by requestors who read tickets through the Service Portal, must not hold this action - otherwise internal comments would become visible to the very people they are meant to be hidden from. See Tickets for how internal versus public comments behave.

Example

Suppose you create a role called "EU IT Manager" with the following configuration:

• Entity scope: EU Engineering
• Permissions: full access to tickets (create, read, update, delete) and read-only access to configuration items

A user whose group carries this role can create, read, update, and delete tickets within the EU Engineering entity and any of its child entities. They can also view configuration items in the same scope. They cannot modify assets, and they have no access to resources in other entities (like US Office) unless another role grants it.