Who may do what

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 — in every project you see

¹ The default. Owners and admins change it under Settings → „Berechtigungen“ (Permissions) — see „What members may do with projects“ below.

For batches it is not access that differs but quantity: owners and admins may use 100 cells per batch, a member 25.

A project is visible to everyone until its access is restricted. Then only the chosen people and groups see it — and owners and admins, who see every project. Whoever sees a project may do in it everything this table allows a member; the rows marked ¹ are set under „Berechtigungen“. Always excepted are restricting and opening, permanently deleting a restricted project and the default project’s export template. How restricting works is under Projects.

What members may do with projects

Under Settings → „Berechtigungen“ (Permissions) owners and admins decide for four things whether „Alle Mitglieder“ (All members) may do them or „Nur Inhaber und Admins“ (Owners and admins only):

Owners and admins may always do all four. For the three project settings, „Alle Mitglieder“ means the members who see the project. Whoever may manage project access adds and removes people and groups on restricted projects they see. An open project has no such list; restricting a project or opening it to everyone, and creating or filling groups, stay with owners and admins.

The setting is available on every plan. Every save is recorded as „Projektrechte geändert“ (Project permissions changed) in the audit trail.

Settings are not open

Reading and changing often diverge here:

A member reads the formats, the label templates and the defaults, which the editor works with, and the project fields and the workspace template, which appear in the project details. They simply do not see the management surface.

Managing members

An invitation can only grant „Mitglied“ or „Admin“. The owner role is not reachable through an invitation.

When an owner or admin becomes a member, they afterwards see only the restricted projects they have access to. The role change names the projects they lose and asks first.

Four constraints that apply on top

1. Nobody changes their own membership. There is no menu on your own row.
2. Only an owner may manage an owner, or grant and revoke the owner role. An admin sees no menu on an owner's row.
3. There is no role change on a deactivated member.
4. The caller must still be active themselves. A deactivated membership loses its rights immediately, even with a valid session.

Billing: seeing is not committing

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.

Security and SSO: reading is not setting up

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.

A restricted project a member has no access to, they see nowhere. One they do see carries „Eingeschränkt“ (Restricted). The list of who else has access they see only if they may manage project access.

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.

The same holds for access: restricting a project, granting access, creating a group and adding a member to a group need the Growth plan or higher. Of these four, a member who may manage project access may do only one: grant access on a restricted project they see — and that too only from Growth up. After a switch to a smaller plan everything stays as it is — restricted projects stay restricted. Opening, revoking access, renaming or deleting a group and taking a member out of a group work on every plan.

The permissions depend on no plan.