Roles & Permissions

Access control (RBAC) is based on permissions in the module:action scheme (e.g. okr:write, person:read, risk:delete, admin:tenant). A role bundles permissions. Roles are defined and assigned per tenant — the same user can be a tenant admin in one tenant and only an observer in another.

Default roles

Every tenant automatically receives four system roles. These are editable but not deletable:

• Tenant Admin — full administration within the tenant (admin:tenant).
• User — read and edit, no delete or administration. Through person:write this role also maintains a person’s Absences.
• Observer — read-only access. Cannot edit anything.
• Security Officer — read access plus visibility administration.

Platform Administrator is a global role (across all tenants) and sits outside this model — it has full access everywhere.

The tenant boundary applies to everyone else without exception. A tenant admin administers their own tenant only; a security officer sees restricted content within their tenant but likewise nothing from other tenants. If you work in several tenants, switch tenants (top right) — your rights always follow the currently active one. This also holds for direct access via a known address or object ID: content from another tenant is rejected regardless of role.

Custom roles — example “propose without write access”

Besides read/write/delete, every Fachmodul also has a “Draft” action (module:draft). It allows submitting a change proposal (draft) that only takes effect after approval — without direct write access to the module. This lets you build e.g. a “Contributor” role: read access plus “Draft” but no “Write” — this person can propose changes but cannot commit anything directly. Anyone who already has “Write” or “Delete” can automatically create drafts too — the permission is purely additive. Create such a role like any other custom role (see below).

Relationships: both ends count

A relationship connects two objects, and the permission is checked for both ends. To link a role to a project you need “Draft” (or “Write”) in both modules — otherwise roleALPHA rejects the proposal.

This also holds when one end is not published yet. If you create a project together with its responsibility in one go, the link is created while the project itself is still a draft — the module it will belong to is checked all the same. If that cannot be determined (because an end neither exists nor is on file as a draft), the proposal is rejected rather than let through.

Cross-cutting permissions

Besides the per-module permissions there are a few that cut across all modules — among them approval:admin: approve drafts regardless of the configured approval mode (see Approval Modes). It is already part of the Tenant Admin role, but you can assign it to a custom role when someone should be able to approve without being an admin otherwise. It only takes effect within the tenant the role is assigned in.

Optional services

Some services are booked or switched on separately and therefore carry their own permission — they appear in a dedicated block below the module matrix:

Permission	Allows	Available when
foresight:read	reading Rehearsal room reports	the rehearsal room is booked
foresight:run	starting a rehearsal run	the rehearsal room is booked
demand:plan	assigning demand and planning capacity	the tenant runs the Demand module
timetracker:report	others’”’”‘/aggregated effort reports	effort tracking is switched on
validator:report	governance findings on an entity	the validator is switched on
demand:report	demand, coverage and competence gaps on an entity	the tenant runs the Demand module
okr:report	progress of the OKRs served by an entity	the tenant runs the OKR module

Splitting foresight:read from foresight:run is deliberate: reading costs nothing, starting costs real money per run and cannot be undone. Grant reading broadly and starting narrowly.

Booking your own effort, or seeing what you yourself are planned on, needs none of these permissions — that works without any role assignment.

Who may configure the structure?

Some changes are not data changes but changes to the tenant’s blueprint. A module write permission is not enough for those — they require admin:tenant, i.e. the Tenant Admin role or a custom role carrying that permission:

Operation	Required
Create, edit, migrate, delete entity types	admin:tenant
Create, edit, translate, delete relationship types	admin:tenant
Set relationship matrix constraints	admin:tenant
Change role definitions and role assignments	admin:tenant

Reading stays open to everyone: entity and relationship types are the vocabulary every view needs in order to display anything.

One level above are the platform operations, for which even a tenant admin is not enough — they require platform_admin:

• Create, rename, assign a custom domain to, or delete tenants
• Manage realms (tenant groups)
• View the tenant list of the entire platform

In the tenant list a tenant admin only sees the tenants they are assigned to, and manages their settings and branding there.

Managing roles

Under Settings → Users & Access → Roles & Permissions all roles appear as a list — just like the Fachservice data. Creating and editing happen in a dialog window:

1. New role: button at the top right → dialog → provide a key (e.g. hr_manager, lowercase/underscore) and a display name, then set the permission matrix (modules × actions) → Save.
2. Edit: pencil icon in the row → the same dialog with the matrix pre-filled → adjust the checkboxes → Save.
3. Active toggle in the dialog: temporarily disable a role without deleting it.
4. Delete: only for custom roles (trash icon in the row); system roles are protected.

Services that are not booked for your tenant still appear in the Optional services block — but greyed out and not selectable, labelled “Not booked for this tenant”. You can see what exists without granting a permission the application would reject anyway. Exception: if a role already carries such a permission (after a contract change, say), the checkbox stays visible and can be cleared — it is never silently dropped on save.

Platform administrators can perform the same management for any tenant from the platform-admin dashboard (Services / Health → Roles).

Assigning roles to users

A user can have any number of roles per tenant — their effective permissions are the union of all assigned roles.

• Within the tenant (User Management): click the shield icon (“Assign roles”) on the user → multi-select the roles → Save.
• In platform-admin (Users): the Roles button on the user → first pick the tenant, then assign roles for that tenant.

platform_admin is unaffected — it is the global platform role, set separately via “Change role”.

Effect & notes

• Revoked permissions take effect after the next token refresh (at the latest on re-login or tenant switch).
• Switching tenant issues a new token carrying the target tenant’s role.
• Per-user role assignment happens in User Management.