Reference
Who can do what
Updated
On this page
What each role can see and change in Zof. Some actions need two roles: a company role in Zof, and admin of the GitHub organization that the Zof GitHub App is installed on.
| Action | Who can do it |
|---|---|
| See Releases, Release policies and code reviews | Anyone in the company |
| Open sealed test reports on Reports | Anyone in the company |
| Link your own GitHub account in Integrations | Anyone in the company |
| Choose your own notification settings | Anyone in the company |
| Start a run or a code review, triage findings, post a review to GitHub | Members and company admins, not viewers |
| Connect GitHub to the company | Company admin. On GitHub, an org admin approves the install. |
| Connect an existing installation | Company admin who is also an admin of that GitHub organization or user account |
| Open Admin in the sidebar, including Release approvers | Company admins, and custom roles with Open Admin. Admin doesn't show for members or viewers. |
| Save release approvers | Company admin who is also a GitHub org admin |
| Save or publish the release policy | Company admin who is also a GitHub org admin |
| See failed deliveries | GitHub org admin |
| Retry a delivery | Company admin who is also a GitHub org admin |
| See a repository's system map, its drafts and its history | Anyone in the company |
| Generate a system map draft, or check one | Members, company admins and custom roles with Work on reviews and releases, not viewers, with their GitHub account linked |
| Accept or dismiss a system map draft, adopt or stop a stored copy | Company admin who is also a GitHub org admin. Accepting, adopting and stopping also need GitHub to share your verified email. |
| See the next step for a chosen repository on Home | Anyone in the company. Viewers are asked to contact an admin when a draft or confirmation is needed; members can generate a draft, and admins confirm it. With no live release policy, Home's setup tip sends people who can publish one to Release policies; everyone else is asked to contact an admin. |
| Approve a change | Release approver for the change's owner, with write access, who didn't write the change |
| Get admin notifications, such as "Merged without Zof's approval" | Company admins |
| Suggest hiding a noisy test in Test Health | Members and company admins, not viewers |
| Suppress a test in Test Health, approve or decline a suggestion, lift a suppression | Company admins. It only hides the test; results, gates and verdicts don't change. |
| Assign or remove a test owner in Test Health | Members and company admins, not viewers |
| Ask Codex, or Claude Code, DeepSeek or Kimi with your own API key, for a fix | Members, company admins, and custom roles granted fix access, while Fix is on. Built-in viewers remain read-only. |
| Open a draft pull request for a fix | The same fix grant, plus a linked GitHub account and repository write access. The Zof Fix App must be installed with its required write permissions. |
| Install or approve expanded Zof Fix App permissions | A GitHub organization owner, once per installation. Permitted members use the configured feature afterward. |
| Turn Fixes for this company on or off, and members' own Anthropic, DeepSeek or Moonshot (Kimi) keys off or back on (all on by default) | Company admins, in Admin › AI model › Advanced |
| Manage personal keys for fixes under Advanced | Anyone in the company, from AI model in the account menu. Each account manages its own keys; requesting fixes still needs fix access. |
| Choose the company provider and model in AI model | Company admins |
| Set up, change or clear the company's Payment test mode | Company admins. Set it up from the locked Payment idempotency test in New run (Set up payment test mode); once it's stored, Admin › Overview links to it (Change payment test mode). |
| Create, edit or delete a custom role, give one to a member or take it away | Company admins, in Admin › Roles and Admin › Users. See Custom roles. |
| Invite a teammate, resend or revoke an invite, copy an invite link, see who joined by email domain | Company admins, in Admin › Users. The invitee joins only by accepting with the invited, verified email. If the invitation email didn't send, Copy invite link gives you a new link to share; earlier links stop working. |
| Suspend or reactivate a member | Company admins, in Admin › Users, not themselves or the last active admin. Per company: it refuses their every request there and revokes its sessions and CLI tokens (all sessions if it was their only company). Zof staff access is unaffected. |
Company roles in Zof
Your company role is set in Zof. There are three built-in roles, and your company can add custom roles. Your persona (the Viewing as menu) changes only your sidebar and what each screen leads with, never what you can do: a company admin keeps Admin in the sidebar on any persona, and a page it hides still opens from search.
Company admin
Sets Zof up for the company. Only a company admin can connect GitHub to the company and save release approvers or the release policy. Company admins see Admin in the sidebar (including Release approvers), as does a custom role with Open Admin. Saving those also needs GitHub org admin. Company admins get the notifications marked "admins", for example when a delivery fails or a pull request is merged without Zof's approval.
Member
Uses Zof day to day. A member sees Releases, Release policies and code reviews. A member can start runs and code reviews, triage findings, post a review to GitHub, generate and check system map drafts, and choose their own notifications.
Viewer
Reads only. A viewer opens the same pages as a member, but can't start runs or code reviews, triage findings, post a review to GitHub, or generate or check a system map draft. The console says "Viewers can't" and names the action.
Permissions by role
Every company role is a set of permissions. Admin › Roles lists them, and Test Permission (under More actions there) tells you whether a person has one.
| Permission | Viewer | Member | Admin | A custom role can hold it |
|---|---|---|---|---|
| View the console | Yes | Yes | Yes | Always included |
| Read the audit trail | Yes | Yes | Yes | Yes |
| Read compliance and evidence | Yes | Yes | Yes | Yes |
| Read reports | Yes | Yes | Yes | Yes |
| Read risk | Yes | Yes | Yes | Yes |
| Read releases | Yes | Yes | Yes | Yes |
| Read code reviews | Yes | Yes | Yes | Yes |
| Read runs | Yes | Yes | Yes | Yes |
| Read tests | Yes | Yes | Yes | Yes |
| Read topology | Yes | Yes | Yes | Yes |
| Read agents | Yes | Yes | Yes | Yes |
| Manage own preferences | Yes | Yes | Yes | Yes |
| Run tests | No | Yes | Yes | Yes |
| Edit tests and projects | No | Yes | Yes | Yes |
| Work on remediation | No | Yes | Yes | Yes |
| Work on reviews and releases | No | Yes | Yes | Yes |
| Operate agents | No | Yes | Yes | Yes |
| Use Studio | No | Yes | Yes | Not yet |
| Create reports and share links | No | Yes | Yes | Yes |
| Open Admin | No | No | Yes | Yes |
| Manage members | No | No | Yes | No, built-in Admin only |
| Manage roles | No | No | Yes | No, built-in Admin only |
| Configure the company | No | No | Yes | No, built-in Admin only |
| Manage the GitHub connection | No | No | Yes | No, built-in Admin only |
| Govern Studio | No | No | Yes | No, built-in Admin only |
| Override governance | No | No | Yes | No, built-in Admin only |
Custom roles
A custom role is a named set of permissions for people who need more than a viewer and less than an admin. A company can have up to 25.
- Create one. In Admin › Roles, click Create role, name it and tick its permissions. View the console is always included.
- Read access. The ten Read permissions decide which areas the role can open. A new role starts with all of them ticked, and a role made before they existed has all of them. Areas move onto these permissions one at a time. Two have moved so far. Read compliance and evidence limits Compliance: its posture, the export history, evidence bundles and retention. Read the audit trail limits the audit events and audit policy reads, which no console page shows yet. The Audit Log tab on Compliance reads the admin audit log, which needs Open Admin, so unticking Read the audit trail changes nothing you can see today. The other areas aren't limited yet. People without a read are told "Your role doesn't include this" on that area's pages. Copilot, search and the command palette already follow all ten: Copilot doesn't read an area the role leaves out and says so, and search and the palette leave out that area's pages and results and say why.
- What it can hold. Any permission marked "Yes" in the last column above. Use Studio isn't available on a custom role yet. You can't give a role a permission you don't have yourself.
- Give it to someone. In Admin › Users, open the person and choose the role in their Role list; custom roles come after the built-in ones. To take it away, choose a built-in role.
- It replaces their built-in role. They have exactly its permissions, even if they were an admin. Their built-in role can't be changed while the custom role is assigned.
- Changes apply at once, on the person's next click. They don't need to sign out.
- Delete. A role can't be deleted while anyone has it. Give them another role first.
- Fix access. Asking for a fix follows Run tests, while Fix is on.
Every change to a role, and every time one is given or taken, is recorded in the audit log: Admin › Audit and data › Audit log.
GitHub roles
These roles are set on GitHub, not in Zof. Zof reads them through your linked GitHub account, which is why linking asks for the read:org scope.
GitHub org admin
An admin of the GitHub organization that the Zof GitHub App is installed on. When the Zof GitHub App is on a personal account, that account's owner counts as its admin. Zof asks GitHub for this role before it lets you:
- change Release approvers or the release policy (with company admin as well);
- see failed deliveries, and retry them (with company admin as well);
- accept or dismiss a system map draft, adopt or stop a stored copy (with company admin as well);
- connect an existing installation.
A company admin who isn't a GitHub org admin sees Release approvers read-only. Anyone who isn't a GitHub org admin sees Release policies read-only, without the draft.
Write access to the repository
GitHub's Write, Maintain or admin access to a repository. A release approver needs it for their approval to count.
Release approvers
Release approver
A person listed in Release approvers for an owner, by name or through a GitHub team. Their approval on GitHub counts for changes to that owner's services when:
- they have write access to the repository;
- they didn't open the pull request or push to it, and, for an agent's change, aren't the person the agent acts for;
- they approved the latest commit, after Verification reported on it.
Being a release approver doesn't need any company role in Zof. Approving happens on GitHub. See Approve a change and Evidence and approvals are tied to a commit.
Joining a company
Joining is by invitation only. An admin invites an email in Admin › Users; the link works once and expires after 7 days. A matching email domain alone never makes anyone a member. People who joined by email domain before this are listed there for the admin to review.