Permissions model

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

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

Account roles

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

• Admin — full instance access; can manage users and every workspace. A global Admin passes every project permission check automatically.
• 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, settings, and custom roles.
• 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. A guest holds zero project permissions — even if a project role is assigned, it's ignored.

Project roles and permissions

A project role is a named set of permissions. Sulu ships three built-in roles — Owner, Member, and Viewer — and lets you define custom roles with any combination of permissions.

Reading needs no permission. Any kind of project membership — a direct role, a group, default access, or a public workspace — lets you read every area of the project: test cases, launches, test plans, defects, dashboards. Permissions only control changes.

The permission catalog

Area	Permission	Grants
Test Cases	Edit	Create and edit test cases, folders, attachments, bulk changes
Test Cases	Delete	Move test cases to Trash
Test Cases	Restore	Restore test cases from Trash
Test Cases	Purge	Permanently delete test cases from Trash
Launches	Edit	Stop launches, set verdicts, manage jobs and environments, ingest reports
Launches	Close	Close and reopen launches
Launches	Delete	Move launches to Trash
Launches	Restore	Restore launches from Trash
Launches	Purge	Permanently delete launches from Trash
Test plans	Edit	Create and edit test plans, manage their cases and executors, run plans
Test plans	Delete	Delete test plans
Defects	Edit	Create and edit defects, link cases and results, create or link Jira issues
Defects	Close	Close and reopen defects
Defects	Delete	Delete defects
Project	Administer	Full project administration: settings, members and groups, trees, custom fields, tags, webhooks, integrations, cleanup rules, audit log

Trash visibility follows the keys: a role with any Delete / Restore / Purge permission for an area can open that area's Trash. Viewers never see Trash; Members can restore from it; only roles with Purge can delete permanently.

Built-in roles

Permission	Viewer	Member	Owner
Test Cases — Edit	—	✓	✓
Test Cases — Delete	—	—	✓
Test Cases — Restore	—	✓	✓
Test Cases — Purge	—	—	✓
Launches — Edit	—	✓	✓
Launches — Close	—	✓	✓
Launches — Delete	—	—	✓
Launches — Restore	—	✓	✓
Launches — Purge	—	—	✓
Test plans — Edit	—	✓	✓
Test plans — Delete	—	—	✓
Defects — Edit	—	✓	✓
Defects — Close	—	✓	✓
Defects — Delete	—	—	✓
Project — Administer	—	—	✓

• Viewer holds no permissions at all — read access comes from membership itself, so a Viewer sees everything and changes nothing.
• Member creates and edits content and restores from Trash, but holds no Delete, Purge, or Administer permission — deletion and project settings are Owner territory.
• Owner holds every permission, including project administration.

Custom roles

Workspace Owners (and global admins) can define their own roles in Workspace Settings → Roles: pick a name and any set of permissions from the catalog above. A custom role can then be assigned anywhere a built-in role can — to project members, groups, invitations, and default access.

• Role names are limited to 50 characters and must be unique within the workspace (case-insensitive).
• The built-in Owner / Member / Viewer roles are read-only — you can inspect their permission matrix but not change it.
• A role that is still assigned to members, groups, pending invitations, or a project's default access can't be deleted; Sulu tells you where it's still in use.

Groups and effective permissions

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

A user's effective permissions in a project are the union of every role they hold there:

• their direct project role, if any,
• the role of every group they're in that's attached to the project, and
• the project's default access role, if one is set.

There is no "higher" or "lower" role — each role contributes its permission set, and the user can do anything any of those sets allows. A direct Viewer who is also in a group attached with a case-editing custom role can edit test cases.

Two exceptions short-circuit the union: a global Admin always holds every permission, and a workspace Guest always holds none.

Default project access

By default, being a workspace member does not open its projects — each person is added to a project directly, through a group, or via an invitation.

A project can opt out of that: in Project Settings → General → Default access for workspace members, pick a role that every workspace member (guests excluded) automatically gets on this project. Set it to Off (the default) to require an explicit invite for everyone.

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. Global admins can also manage any workspace's custom roles from the admin console.