Who may do what
The permission overview — and the four constraints that apply on top of the role.
Three roles per workspace: „Inhaber“ (owner), „Admin“, „Mitglied“ (member). The role belongs to the membership, not to the account — somebody in two workspaces can be owner in one and member in the other.
The signed-in product speaks German, so its labels are quoted in German throughout, with the English rendering in italics.
Daily work is open
| Owner | Admin | Member | |
|---|---|---|---|
| Upload, move, delete, restore | ✓ | ✓ | ✓ |
| Create, rename, delete folders | ✓ | ✓ | ✓ |
| Verify (quick check and from the library) | ✓ | ✓ | ✓ |
| Produce outputs, label them, download them | ✓ | ✓ | ✓ |
| Start batches | ✓ | ✓ | ✓ |
For batches it is not access that differs but quantity: owners and admins may use 100 cells per batch, a member 25.
Settings are not open
Reading and changing often diverge here:
| Read | Change | |
|---|---|---|
| Output formats | everyone | Owner, admin |
| Label templates | everyone | Owner, admin |
| Label defaults and the marking obligation | everyone | Owner, admin |
| Export naming | everyone | Owner, admin |
| Content Credentials — third-party usage | everyone | Owner, admin |
| Retention | Owner, admin | Owner, admin |
| Audit trails (both) and the export | Owner, admin | — |
A member reads the formats, the label templates and the defaults — the editor works with them. They simply do not see the management surface.
Managing members
| Owner | Admin | Member | |
|---|---|---|---|
| See the member list | ✓ | ✓ | — |
| Invite, revoke an invitation | ✓ | ✓ | — |
| Change a role | ✓ | ✓ | — |
| Deactivate, reactivate, remove | ✓ | ✓ | — |
An invitation can only grant „Mitglied“ or „Admin“. The owner role is not reachable through an invitation.
Four constraints that apply on top
- Nobody changes their own membership. There is no menu on your own row.
- Only an owner may manage an owner, or grant and revoke the owner role. An admin sees no menu on an owner's row.
- There is no role change on a deactivated member.
- The caller must still be active themselves. A deactivated membership loses its rights immediately, even with a valid session.
Billing: seeing is not committing
| Owner | Admin | Member | |
|---|---|---|---|
| See the billing page, allowances, plan options | ✓ | ✓ | — |
| Buy, switch plan, change seats, cancel | ✓ | — | — |
| Switch the spending limit on and off | ✓ | — | — |
An admin does not lose the purchase controls silently — a sentence stands in their place. Same for the spending limit: they see the state as a sentence, not as a switch.
SSO: reading is not setting up
| Owner | Admin | |
|---|---|---|
| See the page and its state | ✓ | ✓ |
| See the domain list | ✓ | ✓ |
| Save the connection | ✓ | — |
| Add, verify, release a domain | ✓ | — |
| Switch the sign-in requirement on and off | ✓ | ✓ |
Where an admin tries to save the connection they get no generic permission error but a sentence naming the role.
A member admitted automatically through the identity provider can become „Mitglied“ or „Admin“ — „Inhaber“ is not selectable as a default role.
What a member sees instead
The „Einstellungen“ menu entry not at all, and with it none of the sub-pages. Anyone opening the address directly gets a "not found" page — that holds for the audit export too.
SSO and billing deviate: they show the admin the state and replace the controls with a sentence.
Most often, though, a member does not meet the role boundary in the settings at all but at an allowance refusal while uploading. There they get no dead link but a sentence saying who can act.
A member sees no notice about payment arrears; they get the applicable sentence only at the refusal.
The second axis: the plan
Role and plan are independent. Some owner rights additionally depend on a plan capability — adding a domain and saving an SSO connection, for instance. Both are checked; the role alone is not enough.