Roles & Permissions Overview
How Zenhub decides who can see and change work across your account.
Zenhub access is built from three layers that work together. Each layer answers a different question. Getting the right experience for teammates, stakeholders, and consultants usually means setting more than one of them.
Our philosophy
Most teams need a clear home for day-to-day work, plus a way to bring in people who should only see part of it. Zenhub separates:
Who belongs to your Zenhub account — organization access (billing, seats, invites, and how much of the org someone can see)
What they can do in a specific workspace — workspace access (settings, membership, and whether they can edit or only view)
What they can do on connected GitHub repos — GitHub permissions (view or change issues and pull requests in those repositories)
Organization access is the broad gate. Workspace access is where you fine-tune collaboration for a team or a stakeholder overview. GitHub permissions remain the source of truth for repository data.
The three layers at a glance
Layer | Controls | Learn more |
|---|---|---|
Organization access | Membership in your Zenhub org, seats, invites, org settings, and whether someone sees the whole org or only invited workspaces | |
Workspace access | Who can enter a workspace, whether it is shared or private, and Admin / Editor / Viewer roles inside that workspace | |
GitHub permissions | Read, write, and admin rights on the repositories connected to your workspaces |
TIP: A common setup for an outside stakeholder or consultant is organization Guest (only the workspaces you add them to) plus workspace Viewer. Guests remain Viewers — they can’t move issues, change metadata, or manage the board — except they can create Zenhub Issues and edit the title and description of Zenhub Issues they created. Pair that with GitHub read access on any repos they need to see, or see GitHub Permissions for how to grant that visibility without a GitHub seat.
How the layers interact
Someone must be in your Zenhub organization before workspace and GitHub access matter for day-to-day Zenhub use.
Organization Admins can manage the whole account and have admin-level power across all workspaces in the organization (regardless of specific workspace membership), ie. "god mode".
Organization Guests only see workspaces they are explicitly added to, and in those workspaces they are limited to Viewer access. Guests can’t move issues, change metadata, or manage the board, except they can create Zenhub Issues and edit the title and description of Zenhub Issues they created.
Workspace roles decide whether a member can configure the workspace, collaborate fully, or only view it.
GitHub permissions still apply to connected repositories, and workspace membership does not replace GitHub access on its own — see GitHub Permissions for the one exception, a per-repository visibility setting a workspace admin can enable.
Where to go next
Organization Access — Admin, Member, and Guest roles; seats; invites; defaults
Workspace Access — shared vs private workspaces; Admin, Editor, and Viewer; Guest must be Viewer
GitHub Permissions — repository permission levels, troubleshooting, and letting non-GitHub users see issues