Reference
Roles and access
Everyone in a workspace has a role that decides what they can do. There are four, from read-only up to full control.
You set someone's role when you add them to a workspace, and you can change it later.
| Role | What they can do |
|---|---|
| Viewer | Read-only. Can look at environments, configuration, change sets, work items, pipelines, and runs, but can't change anything. |
| Editor | Everything a Viewer can, plus the day-to-day work: check environments for differences, create change sets, review them (approve or deny), undo one, start and retry runs, manage work items and board columns, and stop tracking a configuration item. |
| Admin | Everything an Editor can, plus setting up the workspace: manage environments and their credentials, mark which environments are production, build pipelines, decide who approves and how many are needed, manage members and access keys, and turn workspace settings like AI access on or off. |
| Owner | Everything an Admin can, plus the two you can't take back: clearing the tracked configuration to start over, and deleting the workspace. The owner is the person who created it, and their role can't be changed or removed. |
Approvers are chosen separately
Requiring an approval is its own setting, not a role. You pick named approvers when you turn on approvals, so review can go to exactly the right people, whatever their role.AI assistants get a lower ceiling
When someone connects an AI assistant, it acts as them, with their role. It also stops at what an Editor can do, even when that person is an Admin or the Owner. So an assistant can look at configuration and put change sets together, and it can't manage members, environments, approval rules, or access keys.
On top of that, a workspace can let an assistant read without letting it change anything, which is how it starts out. See What an AI agent can do.