Dosu uses role-based access control to decide who can change what in your organization. This page explains the three roles, what each one can do, and how roles map to creating Agents, creating Libraries, and setting Library visibility.
What it is#
Every member of a Dosu organization has one role. The role controls which actions that person can take across the dashboard, from inviting teammates to creating Agents and Libraries to changing billing. Dosu has three roles:
- Owner: full control over the organization, including the ability to delete it. Each organization has exactly one Owner, which is the person who created it.
- Admin: can manage members and invitations, change organization settings, create and modify Agents and Libraries, and view billing.
- Member: can sign in and view the organization, including Agents, but cannot create or modify them.
People who interact with Dosu only through an Agent on GitHub or Slack do not need a Dosu account or a role. Roles apply to dashboard users only.
Why it matters#
As an engineering organization grows past a single repo, you need a shared source of truth without giving everyone the keys to it. RBAC lets a platform or admin group own the configuration (which Sources are connected, how Agents respond, which Libraries are public) while the wider team reads, asks, and reviews. That keeps governance in the hands of a small group and reduces the risk of a Library going public when it should remain private.
How to configure#
Roles are assigned and changed in Settings > Organization > Members. From there, an Owner or Admin can:
- Invite a new member by email. New invitations default to the Member role, and you can choose a different role when you invite.
- Change an existing member's role between Owner, Admin, and Member.
- Remove a member or cancel a pending invitation.
To transfer ownership to a different person, contact the Dosu team. Ownership cannot be reassigned from the dashboard.
Roles and permissions#
The table below summarizes what each role can do. Where a row says Owner and Admin, Members have view-only access to that area.
| Capability | Owner | Admin | Member |
|---|---|---|---|
| Sign in and view the organization | Yes | Yes | Yes |
| View Agents, Libraries, and Documents | Yes | Yes | Yes |
| Invite, remove, and change roles for members | Yes | Yes | No |
| Edit organization name and settings | Yes | Yes | No |
| Create and modify Agents | Yes | Yes | No |
| Create, modify, and delete Libraries | Yes | Yes | No |
| Set Library visibility (public or private) | Yes | Yes | No |
| Connect and manage Sources in a Library | Yes | Yes | No |
| View billing and manage the subscription | Yes | Yes | No |
| Delete the organization | Yes | No | No |
| A few details worth calling out: |
- Agents and Libraries are Owner- and Admin-only. Members can view both but cannot create, edit, or delete them.
- Library visibility is an Owner and Admin action. Setting a Library to public exposes its Documents and connected Sources to anyone, including people without a Dosu account, so this is restricted to Owners and Admins. See Public Libraries before you make a Library public.
- Only Owners and Admins manage other members. They can change or remove Members and Admins, but cannot remove or demote the Owner. That is why ownership transfer goes through the Dosu team.
Notes#
- Seats and roles. Every person in the organization counts as one seat, regardless of role. Owner, Admin, and Member seats are all billed the same way. People who ask Dosu through GitHub or Slack do not consume a seat. For how seats and plans work, see Billing and the pricing page.
- Source access is org-wide, not per-role. Once a Source, such as a Slack workspace, is connected to a Library, its content becomes available to everyone in the organization who can access that Library. Roles govern who can connect and configure Sources, not which connected content a Member can read. To narrow what Dosu indexes, scope the connection at the Source itself.
- Single sign-on. If your organization uses SSO, sign-in is handled by your identity provider while the role assigned here still determines what each person can do. See Single Sign-On.
