Roles & Permissions Overview
Understand who can manage your organization, configure workspaces, and collaborate on work.
Zenhub uses two layers of access: roles at the Zenhub organization (your billing and membership boundary) and roles on each workspace (where day-to-day planning happens). Both layers apply together. GitHub repository permissions are a third layer for connected repositories — see GitHub Permissions and Workspace Access.
Zenhub organization roles
Every person in your Zenhub organization has one of two organization roles:
Admin — Full organization governance: billing and subscription, seats and invites, organization settings, and administrative actions across the org. Organization admins are treated as workspace admins on every workspace in that organization for workspace settings and member management.
Member — Standard licensed access to the organization. Members can use workspaces they belong to (or shared workspaces they can join). They do not automatically get organization-wide admin powers or workspace configuration access unless they also hold a workspace admin role (or the workspace is in the open state described below).
TIP: Organization membership controls whether someone is part of your Zenhub account. Workspace membership controls what they can do inside a specific workspace.
Workspace member roles
Inside each workspace, members have one of three workspace roles (plus a separate External role for limited integration access — unchanged by this model):
Workspace admin — Full control of that workspace: change workspace settings (name, privacy, repositories, pipelines, sprints, labels, imports, and similar configuration), delete the workspace, and manage all members and roles.
Workspace editor — Full collaboration on the workspace (move issues on the board, sprint work, roadmaps, and other workspace-scoped edits). Can invite and remove members and change roles for editors and viewers, but cannot assign or remove workspace admins, change an admin’s role, or delete the workspace.
Workspace viewer — Read-only collaboration in the workspace: can view boards, issues in context, and reports, but cannot change workspace settings or manage members. Viewers cannot invite others or change who has access.
Major capabilities at a glance
This is not an exhaustive permission matrix, but it covers the actions teams ask about most often.
Action | Org admin | Workspace admin | Workspace editor | Workspace viewer |
|---|---|---|---|---|
Organization billing & org settings | Yes | — | — | — |
Workspace settings & configuration | Yes (all workspaces) | Yes | No | No |
Delete workspace | Yes (all workspaces) | Yes | No | No |
Invite / remove members | Yes (all workspaces) | Yes | Yes (not admins) | No |
Change member roles | Yes (all workspaces) | Yes | Yes (not to/from admin) | No |
Collaborate on the board (move issues, sprints, etc.) | Yes | Yes | Yes | View only |
Workspaces without a workspace admin
If a workspace has no members with the workspace admin role, it is treated as an open workspace for permissions: every workspace member can perform workspace configuration actions (same as an admin), including the first person who joins. This allows users to manage workspaces that never had an explicit admin assigned. Once at least one workspace admin exists, only admins (and organization admins) can change workspace settings; editors and viewers follow the rules above.
Private workspaces
Private workspaces require explicit workspace membership to see the workspace at all. Organization membership alone is not enough for private workspaces. Role rules (admin / editor / viewer) apply after someone is a member. See Workspace Access for privacy and inviting members.
GitHub permissions still matter
Workspace roles control Zenhub workspace behavior (settings, membership, and workspace-scoped collaboration). For issues on connected GitHub repositories, users still need appropriate GitHub read or write access to view or edit those issues on GitHub. A workspace viewer may be read-only in Zenhub while GitHub access is configured separately per repository.
Defaults
Creating a new workspace automatically makes you an admin of that workspace. Inviting others to the workspace makes them workspace editors by default.
FAQ
Q: What is the difference between a Zenhub organization admin and a workspace admin?
A: Organization admins manage the whole Zenhub account (billing, seats, org settings) and have workspace admin powers on every workspace. Organization admins also bypass workspace privacy controls (ie. organization admins have access to all private workspaces even if they're not explicit members). Workspace admins only control that one workspace’s settings and members.
Q: Can a workspace editor make someone else an admin?
A: No. Only workspace admins and organization admins can assign the workspace admin role or change an existing admin’s role.
Q: Can a workspace viewer comment or move issues?
A: Viewers have read-only access for workspace-scoped collaboration in Zenhub. Editing issues may still depend on GitHub repository permissions for connected repos. The "Workspace viewer" role is designed specifically for external collaborators who need to see the work happening, provide guidance, but should not be able to make any changes to the work items.
Q: In my organization members list I also see members with an "External" role. What is that?
A: External is a separate, limited membership type used for specific integration scenarios. For example, when the Slack integration is setup and a Slack user leaves a comment on a Zenhub issue via Slack, without having membership to the Zenhub organization. These users can only interact with Zenhub data via that third-party integration and cannot log into the Zenhub at all.