Reference
Roles & permissions
Two independent controls: what a member can do, and which projects they can see at all.
Workspace roles: what a member can do
Three built-in roles, each a set of feature-level permissions (settings, projects, suites, generate, API Runner, reports, runs, bugs, client issues):
| Role | Access |
|---|---|
| Owner | Everything, implicitly. The workspace owner never needs a role assigned. |
| Admin | All permissions, including owner-only settings (branding, email, team, roles, integrations). |
| Member | Everything except owner-only settings: can generate, run, manage bugs, create suites and client issues. |
| Viewer | Read-only everywhere. Generate, API Runner, and Test Runs are hidden from navigation; suites and bug reports are visible but not editable. Enforced on the server, not just hidden in the UI: a viewer hitting a write endpoint gets a clear permission message, not a bare error. |
Need something between these? Settings → Roles lets an owner define custom roles with any combination of the same permission keys.
Project-scoped access: what a member can see
Independent of role: a member can additionally be scoped to specific projects. An owner sees every project by default; a member sees only the projects they've been explicitly assigned to, on Projects, Suites, MCP Runs, Bugs, Runs, and the Dashboard. Assign project access from a project's Team Members tab (owner-only).
Putting the two together
Inviting people
From Settings → Team, invite by email and assign a role. If you also want to limit which projects they can see, assign project membership from within each project's Team Members tab after they accept.