> ## Documentation Index > Fetch the complete documentation index at: https://docs.duvo.ai/llms.txt > Use this file to discover all available pages before exploring further. # Roles and Permissions > The six team-level roles, the permissions each one grants, and how the Builder ownership model works. Duvo uses team-level roles to control what each member can see and do within a team. Every team member is assigned exactly one role, and roles are scoped per team — a user can have different roles in different teams. *** ## Understanding the Roles Each role is designed for a distinct type of team member. The key question is: **what does this person need to do in Duvo?** * **Clarity Member** — For people contributing process knowledge. They can add interview evidence and manage their own captures, but they cannot edit generated process content or use agents and connections. * **Member** — For people who use agents but do not build them. Members can run agents shared with them, connect their own connections, and manage files — everything they need to get work done with agents others have created. * **Builder** — For people who create agents and help maintain Clarity. Builders can build, test, and iterate on their own agents, create Clarity processes, and edit any Clarity process they can access in their team. They can delete only the Clarity processes they created. * **Manager** — For people who oversee agents across the team. Managers can create, edit, and delete any agent — not just their own. They also manage queues and have full access to connections and resources. * **Administrator** — For people who run the workspace. Administrators have all the capabilities of a Manager, plus they can manage team members, roles, settings, and view every team member's schedules and run results in one place. * **Owner** — For the person ultimately responsible for the team. Owners have full Administrator access plus control over billing, team deletion, and the ability to assign the Owner role to others. Every team must have at least one Owner. *** ## Permissions by Role ### Team Management | Capability | Owner | Administrator | Manager | Builder | Member | Clarity Member | | - | - | - | - | - | - | - | | Manage billing | Yes | Yes | --- | --- | --- | --- | | View and edit team settings | Yes | Yes | --- | --- | --- | --- | | Delete team | Yes | Yes | --- | --- | --- | --- | | Add or remove team members | Yes | Yes | --- | --- | --- | --- | | Update member roles | Yes | Yes | Yes | --- | --- | --- | | Invite new members | Yes | Yes | Yes | --- | --- | --- | | View team members | Yes | Yes | Yes | Yes | Yes | Yes | ### Agents "Own only" means the permission applies only to agents the user created. | Capability | Owner | Administrator | Manager | Builder | Member | Clarity Member | | - | - | - | - | - | - | - | | Create new agents | Yes | Yes | Yes | Yes | --- | --- | | Edit any agent | Yes | Yes | Yes | --- | --- | --- | | Edit own agents | Yes | Yes | Yes | Yes | --- | --- | | Delete any agent | Yes | Yes | Yes | --- | --- | --- | | Delete own agents | Yes | Yes | Yes | Yes | --- | --- | | Create revisions on any agent | Yes | Yes | Yes | Own only | --- | --- | | Create revisions on own agents | Yes | Yes | Yes | Yes | --- | --- | | View and run agents | Yes | Yes | Yes | Yes | Own only | --- | | Manage agent folders | Yes | Yes | Yes | Yes | --- | --- | ### Connections and Resources | Capability | Owner | Administrator | Manager | Builder | Member | Clarity Member | | - | - | - | - | - | - | - | | Access connections | Yes | Yes | Yes | Yes | Yes | --- | | Add and manage custom connections | Yes | Yes | Yes | --- | --- | --- | | Manage files and skills | Yes | Yes | Yes | Yes | Yes | --- | | Manage the team's API keys | Yes | Yes | Yes | --- | --- | --- | | Create and manage own API keys | Yes | Yes | Yes | Yes | Yes | Yes | | Access logins | Yes | Yes | Yes | Yes | --- | --- | ### Analytics and Intelligence | Capability | Owner | Administrator | Manager | Builder | Member | Clarity Member | | - | - | - | - | - | - | - | | View team insights | Yes | Yes | --- | --- | --- | --- | | View all team members' runs | Yes | Yes | --- | --- | --- | --- | | Access Clarity | Yes | Yes | Yes | Yes | Yes | Yes | | Contribute process evidence | Yes | Yes | Yes | Yes | Yes | Yes | | Create Clarity processes | Yes | Yes | Yes | Yes | --- | --- | | Edit accessible team process content | Yes | Yes | Yes | Yes | --- | --- | | Delete any Clarity process | Yes | Yes | Yes | --- | --- | --- | | Delete own Clarity processes | Yes | Yes | Yes | Yes | --- | --- | | Generate, share, and set access | Yes | Yes | Yes | Own only | --- | --- | | Manage Clarity settings and structure | Yes | Yes | Yes | --- | --- | --- | | Manage queues | Yes | Yes | Yes | --- | --- | --- | Clarity content editing is team-wide for Builders without bypassing restricted-process access. A Builder can rename an accessible process, update its guidance, and edit generated process content even when another teammate created it. The creator or a Manager must still handle generation, sharing, visibility, and access. Builders can delete only processes they created; Managers can delete any team process. The **Manage Clarity settings and structure** permission lets team Owners, Administrators, and Managers maintain process nodes for their team. * **Open and understand the landscape** — All organization members can open **Process Landscape**. Folders and capabilities form the visible organization skeleton. Inaccessible processes appear as **Restricted process**; only granted processes render in full. * **Maintain process nodes** — Managers can maintain process nodes for teams they manage. Organization Executives, Owners, and Admins can maintain the skeleton and all process nodes. * **Generate the landscape** — Only organization Executives and Owners can generate **Process Landscape**. * **Assign ownership** — Process ownership assignment remains limited to organization Admins, Owners, and Executives. *** ## Builder Ownership Model The Builder role uses an ownership model for agent editing. When a Builder creates an agent, they become its owner and have full editing capabilities on that agent — including modifying the AOP, adding connections, creating new revisions, and deleting the agent. For agents created by other team members, Builders have view and run access only. To edit agents they did not create, a user needs the Lead Builder role or above. Inside an automation, each agent keeps its own rule. Changing one agent there needs edit rights on that agent: its build in a draft, its triggers and schedules, or removing it. Making a draft active, or discarding it, counts as changing the agents the draft changes. A Builder can do these for the agents they created, even when the automation also holds a teammate's agents. Changes to the automation as a whole affect every agent in it: renaming or deleting it, its queues, tabs and overview. A Builder can make these only when they created every agent in the automation. Adding an agent to an automation needs both. Users with the Lead Builder role or above can change any automation. Clarity intentionally works differently: Builders can edit process content across their team so process documentation stays collaborative. Ownership still controls deletion and administrative actions. *** ## Related Topics How teams work and how to structure them How roles apply when reviewing AOP changes on high-risk agents This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.