Permissions (RBAC)
Role-based access control with entity scoping and hierarchy inheritance
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".
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.
Need help?
If you can't resolve the issue yourself, our support team is here to help. Contact support.
Areas Covered by Permissions
The following areas are subject to permission checks:
| Area | Description |
|---|---|
| Entities | Organisational units |
| Configuration items | Infrastructure assets |
| Vendors | Hardware and software suppliers |
| Types | Device models |
| Applications | Applications and capabilities |
| Business processes | Business workflows |
| Tickets | Incidents, problems, and changes |
| Controls | Security and compliance controls |
| Control tests | Control test executions |
| Issues | Risk findings |
| Users | User accounts |
| Groups | User groups |
| Roles | Permission sets |
| Audit logs | Immutable activity trail |
Special Permissions
Some permissions use non-CRUD actions:
| Area | Action | Scope | Description |
|---|---|---|---|
| Management | access | Global only | Access to the management interface |
| Billing | manage | Global only | View/manage billing, invoices, plan changes |
| Risk Value Insight | read | Global or entity | View financial values on business processes, RPO/RTO on applications, and total financial exposure in the business impact analysis on tickets and issues |
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.