Permissions model

Sulu has three independent role dimensions. A person can hold a role at each level, and the levels don't imply one another — being a workspace Owner doesn't make you a project Owner, and vice-versa.

Level	Roles	Scope
Account (global)	Admin · User	The whole Sulu instance
Workspace	Owner · Member · Guest	One workspace (tenant)
Project	Owner · Member · Viewer	One project

Account roles

Set on the admin Users page (global admins only).

• Admin — full instance access; can manage users and every workspace.
• User — a standard account. What they can actually see and do is decided by their workspace and project roles.

Workspace roles

• Owner — manages the workspace: members, billing/seats, and settings.
• Member — belongs to the workspace and can be added to its projects. Consumes a seat.
• Guest — a free, read-only role scoped to specific projects. Guests never consume a seat and don't appear in the member roster. Use them for stakeholders who should see results but not change anything.

Project roles

In Allure terms: Viewer ≡ Read, Member ≡ Write, Owner ≡ Owner.

• Owner — edits project settings, members, custom fields, trees, and tags; can delete the project.
• Member — authors and runs test cases and launches; can't change project settings.
• Viewer — read-only.

See Members & roles for how to grant project access.

Groups and effective role

A group is a workspace-scoped set of users that can be attached to a project with a project role — handy for patterns like "the QA team has Read on every project."

A user's effective project role is the highest of:

• their direct project role, if any, and
• the role granted by every group they're in that's attached to the project.

So a Viewer who is also in a group attached as Member is effectively a Member.

Global admins everywhere

A global Admin can manage any workspace or project regardless of their workspace/project role — the backend treats global admin as a bypass on those checks.