Roles and who may do what

Every user has a role, and the role is what decides which screens they see and what they may do on them. Two roles ship with the system, and an administrator can define more above them. A user's role is shown in the account card at the foot of the sidebar.

The two built-in roles

Role	What it holds
Administrator	Everything. Including permissions added in later versions — they are included automatically, with nothing for anyone to remember to grant
Operator	The default. Sees, exports, executes and reports

Both are marked as built-in and cannot be edited or deleted. They can be duplicated, and that is the right starting point for a custom role.

What an operator does

This is what ships. An administrator can change it.

Kind of action	What it covers
Sees and filters	The calendar and events, tasks, the server list, databases, equipment, the vulnerability register, system connections, business impact, recommendations, dashboards, alerts and the activity board
Exports	Events, servers, vulnerabilities, databases, equipment and recommendations — to CSV or Excel
Executes and reports	Sets an event's execution status, fills in the checklist afterwards, marks a host as handled against a vulnerability, and sends the recommendation email to the system manager
Edits within their own scope	Their own dashboards, and a database's metadata fields

And what they cannot do: create an event, move its window or cancel it; touch settings; manage roles; read the change log.

An additional role

An administrator creates a role by name and chooses what to start from — empty, or a copy of an existing role's stated grants. Permissions are edited and members are added after it exists.

• One role can be marked as the default: it is what a user with no role assignment gets.
• Deleting a role moves its members to another role in the same operation. A role cannot be deleted leaving users with nowhere to go, and the screen asks you to type the member count to confirm.

How the permission catalog is organized

Permissions are grouped by area of the system. Each area has one access level — none, view, edit, manage — and a higher level contains everything below it. Beside the level sit independent actions: export, cancel, approve. An action that requires a minimum level says so on the screen rather than failing quietly.

A permission in one area never implies a permission in another. That is what makes it possible to give someone edit on the systems register without incidentally handing them access to server records.

Two guardrails that cannot be bypassed

• Someone can always manage permissions. An operation that would leave the system with nobody able to manage roles is refused.
• You cannot lock yourself out. A role manager cannot remove their own last source of that permission.

Permissions and access tokens

The permission keys are also the scopes an access token can carry. A token gets the intersection of the scopes chosen for it and the live permissions of whoever issued it — when their permissions narrow, the token narrows with them. A token never receives the administrator short-circuit, even when an administrator issued it.