Roles and permissions

Access in Taiga is two independent questions. Your role decides what you can do. Your factory memberships decide where.

One role, held at the organization

You have a single role, and it is the same everywhere you go.

There is no separate role for a factory or for a product. A viewer is read-only in every factory they are on; a member has the same abilities in each of them.

This is a deliberately lean model, and it has a limit worth knowing up front: you cannot make someone an administrator of one factory only. Changing what a person can do changes it organization-wide. What you can vary is where they can do it.

Factories are the unit of access

You are added to a factory, and that gives you access to the products in it. Products are not granted separately, with one exception: whoever creates a product is a direct member of it, and keeps that access even after leaving its factory. A product’s member list is a view of who has access and where it comes from, not a place to add people.

So there are two levers, and they do different jobs:

• To change what someone can do, change their role.
• To change where they can do it, change which factories they are on.

Owner and admin are the exception to the second one. They reach every factory and product whether or not they are a member, because an administrator who can be locked out of a factory cannot administer the organization.

The four system roles

Role	In one line
Owner	Everything, including irreversible actions.
Admin	Everything except erasing the organization.
Member	Does the work: products, initiatives, 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 products	●	●	●	●
Create and edit products	●	●	●
Delete products	●	●
Generate product documents	●	●	●
Read initiatives	●	●	●	●
Edit initiatives	●	●	●
Generate initiatives	●	●	●
Read factories	●	●	●	●
Create and edit factories	●	●
Edit factory instructions	●	●	●
Delete factories	●	●
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 questionnaires	●	●	●	●
Import, answer and download questionnaires	●	●	●
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.

Two things the table cannot show

For members and viewers, every row that touches a product or factory is bounded by where they have access. “Create and edit products” means the products in the factories you are on, plus any product you created, not every product in the organization. Owners and admins are not bounded this way, as described above. The table answers what you may do; your factories answer where.

A few actions carry a second, stricter check. Organization-level knowledge is the one to know about: adding or changing it takes an owner or admin, even though the knowledge rows above are open to members. It is inherited by everything underneath, so it is treated as organization governance rather than as reference material. Factory and product knowledge behaves exactly as the table says.