Staff & Roles (IAM)
This page controls who can do what in the admin area. Here you manage roles (e.g. "Sales Manager" or "Support"), see in a matrix which role has which permission, and can set individual exceptions (overrides) for specific users. The older "Team" menu item automatically redirects here.
What can I do here?
- Create new roles, edit or delete existing ones
- Toggle individual permissions per role and area in the permission matrix
- Assign or remove roles for a specific user
- Set targeted exceptions (overrides) for individual users that allow or forbid a permission — independent of their role
- View a user's effective (actually applied) permissions
- Reset a staff member's access (delete password + 2FA, send an email to set a new password)
Step by step
- Create a new role: Switch to the "Roles" tab and click "Create new role". Fill in the technical name, display name, description, color and hierarchy level, choose the desired permissions, and save.
- Toggle a permission: Open the "Permission matrix" tab. Expand the desired area (e.g. "Orders") and click the checkmark/cross in the column of the relevant role.
- Assign a role to a user: Open the "User permissions" tab, select the user, and click "Assign role" in the "Assigned roles" section.
- Set an individual exception: In the same tab, click "Add override", choose the permission, decide "Allow" or "Deny", set the scope, and save with a reason.
- Reset access: If a user has a linked admin account, you'll find a "Reset access" button in the "User permissions" tab — this deletes password and 2FA, ends all sessions, and sends an email through which the staff member sets a new password. Their account and profile remain unchanged — no new onboarding.
Fields explained
| Field | Meaning | Notes/Impact |
|---|---|---|
| Technical name | Internal role identifier | Not editable for system roles |
| Display name | Visible name of the role | Freely chosen |
| Description | Short description of what the role is for | Optional |
| Color | Color used to mark the role | Shown as a badge |
| Hierarchy level | Number from 1–100 describing the role's rank | Higher = more weight in the hierarchy |
| Permissions | List of individual rights, grouped by area (e.g. Products, Orders, Settings) | Fully read-only in the role edit dialog for system roles (view only); for system roles, permissions can only be changed via the Permission Matrix — there, every click takes effect immediately, with no confirmation dialog |
| Override – permission | The specific permission the exception applies to | Chosen from a dropdown |
| Override – action | "Allow" or "Deny" | Overrides the role-based permission for this user |
| Override – scope | Scope: All, Department, Team, Own | Limits which data the exception applies to |
| Override – reason | Free-text note on why the exception was set | Recommended for traceability |
Values & statuses
Default roles (examples from the system)
| Value | Plain meaning | What happens |
|---|---|---|
| Geschäftsführer (Managing Director) | Full access to all areas of the system | Highest hierarchy level |
| Vertriebsleiter (Sales Manager) | Leads the sales team with full CRM access | Sees and edits all sales data |
| Vertriebler (Sales Rep) | Sales staff with access to their own data | Usually restricted with scope "Own" |
| Buchhaltung (Accounting) | Accounting and finance management | Access to invoicing and finance areas |
| HR-Manager | HR administration and staff management | Access to HR modules |
| Support | Customer support and ticket handling | Access to support/CRM areas |
| Marketing | Marketing, newsletter and content management | Access to marketing modules |
| Lager (Warehouse) | Warehouse and inventory management | Access to inventory areas |
| Nur Lesen (Read-only) | Read access to all key areas | No edit rights |
The four roles that ship with every workspace
Since 2026-08-22 every workspace starts with four system roles that take effect immediately. They are cut so that the activity at the end of a permission sets the tier: reading sits below writing, writing below managing.
| Role | Hierarchy level | What it may do |
|---|---|---|
| Super-Administrator | 100 | Everything the workspace offers - the only role that reaches the sensitive areas |
| Administrator | 80 | Manage and delete everywhere else. Approvals, refunds, payment captures, invitations and access resets sit here. No salaries, no bank accounts, no accounting, no audit trail |
| Redakteur (Editor) | 50 | Read and edit everything that is not sensitive - content, master data, products, orders, CRM. No approvals, no money, no salaries |
| Betrachter (Viewer) | 10 | Read, plus the self-service functions for oneself (own tasks, own signatures, own appointments). No editing, no sensitive areas |
Sensitive here means: salary and compensation data, salary bands, bank accounts, accounting, cash flow, invoices, revenue figures, billing, the audit trail and privacy requests - including the actions that belong to them, such as posting, exporting, bank reconciliation and compensation approvals. These areas are open to the super-administrator only; viewer, editor and administrator see none of it, not even read-only.
Changed on 2026-08-23. Until then the administrator was the lowest tier with access to the sensitive areas. The audit trail decided it: whoever can read and manage it manages the record of their own actions. To open these areas to somebody below the super-administrator, create your own role and grant the permissions deliberately - the four shipped roles no longer cover that case.
No operator-plane permission is part of any of the four roles. Those belong to the SELLERLOGIC console and are never granted to a workspace.
Roles without a "System role" label are custom and can be fully edited or deleted.
Override action
| Value | Plain meaning | What happens |
|---|---|---|
| Allow | The permission is specifically unlocked for this user | Applies on top of the role's permissions |
| Deny | The permission is specifically blocked for this user | Applies even if an assigned role would otherwise grant it |
Override scope
| Value | Plain meaning | What happens |
|---|---|---|
| All | Exception applies to all data | No restriction |
| Department | Exception applies only to the user's own department's data | Restricted access |
| Team | Exception applies only to the user's own team's data | Restricted access |
| Own | Exception applies only to the user's own records | Most restricted |
Frequently asked questions
When does a permission change take effect?
Immediately. If you withdraw a role or a permission, deactivate an account, or change an individual override, the affected user's running session is re-evaluated at once: their very next action already runs with the new permission set - on deactivation they are signed out. They don't have to do anything; an active user whose access remains valid keeps working without interruption.
What does a user see of areas they have no permission for?
Nothing any more. The sidebar, the product rail, and the action buttons follow the actual permissions of the signed-in session: areas without a read permission do not appear in the menu at all, and create/edit buttons are missing without the matching write permission. The self-service areas (such as "My area" in HR) remain visible to every employee. If someone opens a URL without permission directly, an explanatory "No access" page appears with a hint to contact the administrator - not an empty page full of error tiles.
What's the difference between this page and "Staff & Access"?
"Staff & Access" manages the person's data (contact, department) and offers a quick role assignment. "Staff & Roles" (IAM) is the full management: here you create roles, edit the permission matrix in detail, and set individual overrides.
Can I edit system roles?
The role edit dialog is completely read-only for system roles (e.g. Admin, Manager, Viewer) — name, description, color, hierarchy, and permissions can only be viewed there. You can only change a system role's permissions through the Permission Matrix: clicking the check/cross in that role's column toggles the permission immediately, with no separate confirmation. Proceed carefully, since this affects every user with that role right away.
What is "Reset access" for?
This feature is meant for security incidents or when a staff member has lost access: their password and two-factor data are deleted, all active sessions end, and an email to set a new password is sent. The staff member's account and profile remain unchanged.
What happened to the "Team" menu item?
"Team" is a legacy menu item that automatically redirects to this page (Staff & Roles).
Why can't I grant some permissions?
You can only grant permissions that you hold yourself. If you try to give a role, a user, or an override a permission your own account does not have (e.g. "iam:manage"), the action is rejected. This prevents anyone from escalating their own rights through the permission-management screens. Holding a wildcard permission (e.g. "hr:*") lets you grant the individual permissions beneath it (e.g. "hr:absences:read"). Only the two highest roles — Owner and Super Admin — are exempt from this ceiling.
Who may assign the "Owner" or "Super Admin" roles?
These two roles bypass every permission check and therefore cannot be handed out through normal team management. The "Super Admin" role may only be assigned by an Owner or Super Admin; the "Owner" role only by the Owner. Invitations or role changes that violate this are rejected.
Why can a role edit an invoice but not send it?
Because sending has been a permission of its own since August 2026. Until then a single permission ("Edit invoices") opened both: changing the draft and mailing the finished invoice to the customer. Those are two very different things - one stays in the house, the other does not. Under Invoices the role dialog therefore now offers three permissions: Read, Edit and Send. Telephony carries the same split: Edit telephony sets the system up, Place a call actually dials a number.
Does an existing role lose anything?
No. Every role that could already edit invoices received the new send permission automatically, and every role that could set telephony up likewise received the permission to place a call. Nothing that worked yesterday stops working today. What is new is that you can now take sending away on its own, without taking editing with it - which is exactly what the split is for.
A staff member reports an empty menu. What do they actually see?
An empty navigation no longer exists. Anyone who is signed in always sees at least Dashboard, My profile and Sign out. If no permissions are recorded for their account, a note appears at the foot of the navigation as well. That note names both possible causes, because they cannot be told apart from the outside: either no access has been granted yet, or the permission service is currently unreachable. What it is explicitly not is a defect in the application. Your next step is the same in both cases - give the account a suitable role on this page; if the note persists afterwards, contact operations. If an account does hold permissions but none of them opens a single menu entry in the product currently selected, the note says exactly that; the other products remain reachable.