Roles and permissions

Access in Taiga is a role held at a scope. The role decides what you can do; the scope decides where.

Scopes

A role is granted at the organization, a team, or a project.

Someone can hold different roles at different scopes, and this is the normal case rather than an edge case: an organization member who owns one project and can only read another.

Two organization roles are deliberate exceptions. Owner and admin retain access to every team and project, because an administrator who can be locked out of a team cannot administer the organization. Every other role sees only what it is a member of.

The four system roles

Role	In one line
Owner	Everything, including irreversible actions.
Admin	Everything except erasing the organization.
Member	Does the work: projects, backlogs, documents, generation.
Viewer	Reads.

Roles rank from owner down to viewer, and you can only manage people ranked below you.

What each role can do

	Owner	Admin	Member	Viewer
Read projects	●	●	●	●
Create and edit projects	●	●	●
Delete projects	●	●
Generate project documents	●	●	●
Read the backlog	●	●	●	●
Edit the backlog	●	●	●
Generate the backlog	●	●	●
Read teams	●	●	●	●
Create and edit teams	●	●
Delete teams	●	●
Read users	●	●	●	●
Manage users	●	●
Manage invitations	●	●
Organization settings	●	●
Read policies and standards	●	●	●	●
Edit policies and standards	●	●
Read knowledge	●	●	●	●
Add and edit knowledge	●	●	●
Delete knowledge	●	●	●
Read repository connections	●	●	●
Manage repository connections	●	●
Manage roles	●	●
Read the audit log	●	●
Export organization data	●	●
Erase the organization	●

The last row is the only thing an owner can do that an admin cannot. Erasure is irreversible, so it is held one rung higher than everything else on purpose.

The other line worth noticing is knowledge. Members can add, edit and delete it, while policies stay read-only to them. That split is intentional: reference material is part of doing the work, and governance is not.

Custom roles

You can define roles beyond the four above. They rank at the member tier, which has two consequences worth knowing before you rely on them:

• Admins can assign custom roles and manage the people holding them.
• Someone holding a custom role can only manage people below the member tier.

So a custom role is a way to shape what a member can do. It is not a way to create a second kind of administrator.

Checking the matrix

This table is transcribed from the permission matrix in the codebase, correct as of writing. It is the most drift-prone page on this site, because a capability can be added without anything here noticing.

If a permission question matters for a compliance answer, confirm it in the product rather than trusting this page.