Permissions / Roles & permissions
Roles & permissions
What Owner, Admin, Member, Guest, and custom roles can do in a TAM workspace and project, and how team types differ from access levels.
Every workspace member has a role that determines what they can do, from reading issues to managing billing. Roles are assigned in Workspace Settings → Members.
Roles
- Owner. Full access to everything in the workspace, including billing, deleting the workspace, and transferring ownership. Usually one person per workspace.
- Admin. Same default access as Owner except actions protected by
workspace:manage, including inviting, changing the role of, or removing members. Can manage projects, teams, and integrations, and can view the member list. A custom role may be grantedworkspace:manage. - Member. The main working role: creates and edits issues, comments, assigns work, reads and writes the wiki, and uses MCP tools. Cannot change workspace settings, member roles, or billing.
- Guest. Read-only: sees issues, projects, and the wiki, but cannot create or edit them. A good fit for stakeholders who need visibility without edit access.
- Custom role. Workspace managers can create a named role from the permission catalog and assign it to members or invitations. TAM enforces the stored permissions, not the role's display name.
Team types
Teams group members by organizational shape, not by access level; a team's type doesn't change what its members can do on issues.
- Squad. A small cross-functional team focused on a specific product area.
- Guild. A community of practice spanning multiple squads, for example all backend engineers.
- Chapter. A larger organizational grouping, usually spanning several guilds or squads.