Organization and project roles that control what users can do.
Authorization is role-based and applies at two levels: the organization and the individual project. A user can hold different roles in different places, so you grant exactly the access each person needs.
Organization roles
| Role | Capability |
|---|---|
org_owner | Full org control — members, folders, projects, billing |
org_admin | Operational admin — members, folders, projects |
org_member | Access only via folder or project membership |
A new user’s first sign-in creates a personal organization where they are org_owner.
org_owner and org_admin bypass project-level checks and effectively hold owner access on every project in the organization, regardless of explicit project-level viewer assignments.
Project roles
| Role | Typical capabilities |
|---|---|
owner | Full control, including deletion and ownership |
admin | Manage members and settings |
editor | Create and edit content, branches, and commits |
viewer | Read-only — no edits, commits, or branch management UI |
For org_member, effective project role is the highest role from direct project membership, inherited folder grants, and group grants.
Granting access
Access can be granted to individual users or to groups, at the folder or project level:
Choose scope
Folder-level for a set of projects, or project-level for one.
Prefer groups for teams
Add a group so membership changes propagate automatically.
Assign least privilege
Start from viewer and elevate only as needed.
Review periodically
Remove access that is no longer required.
Least privilege
Reserve owner/admin for those who manage settings, membership, or the
project lifecycle. Most contributors need editor; most readers need
viewer.
Related
For day-to-day team management, see Teams and Access.
Last updated on