Tutorial
Create custom roles and permissions
Four built-in roles, a permission grid and custom roles of your own: control who can do what in Zuuna, on every plan, including the free one.
Last updated:
Who may delete cards, who invites new people, and who sees billing? In Zuuna a permission grid answers that: four built-in roles as the starting point, custom roles for everything in between. And unlike many tools, there is no special tier to buy: roles and permissions come with every plan, including the free one.
What you need
- Any plan: roles cost nothing extra (pricing).
- Access to Administration: you are the workspace owner or hold the
members.manageRolespermission. - A team in the workspace, if not yet: invite your team and set roles.
1. Start from the four built-in roles
Every workspace starts with four roles. Superadmin is the owner role and can always do everything. Admin can do everything except a handful of protected keys: more on those in a moment. Team member is the everyday role: create boards, groups and cards, edit, assign and delete cards, log time, manage views, fields and automations. Guest starts with not a single permission: watching only.
Admin, Team member and Guest can be reshaped freely. Only the Superadmin role is fixed: there must always be someone who is guaranteed to reach everything.
2. Build a custom role in the grid
Open the account menu top right → Administration → User management → Permissions. The page is a grid: roles side by side, permissions in rows, grouped by topic: boards, cards, members, sprints, poker and more. Create a new role, give it a name that says what it is, and tick exactly the keys it needs. Roles are per workspace, and every member carries exactly one.
3. Typical cuts
- Read-only for stakeholders: a role with no write keys at all, or simply the Guest role. Whoever has nothing ticked can view boards but change nothing.
- Sprint lead without admin rights: a role with the sprint keys (
sprints.editand its siblings) but without member or workspace management. - Moderating poker:
poker.moderatefor the person running the estimation rounds; voters only needpoker.join.
To be honest about the mechanics: the role decides who may operate a feature, but whether the feature exists in the workspace is decided by the plan. Sprints and poker themselves belong to the Developer plan; you can still grant their keys on any plan.
4. Know the protected permissions
Six keys belong to the owner role only by default: billing.manage (billing), workspace.delete (deleting the workspace), members.manageRoles (assigning roles), members.changeEmail (changing a login address is a takeover vector), members.impersonate (logging in as someone else) and security.manage (a 2FA mandate, IP allowlist and SSO can lock members out).
You can still grant them, deliberately, through a custom role. But only as the owner yourself: a delegated admin who manages roles cannot build or assign a role that carries these keys. They cannot be passed along casually, which is exactly the point.
5. Assign the role and verify
Under User management → Members you assign the new role: one person at a time or several at once. Verifying is easy: the interface hides buttons whose permission is missing. You do not have to rely on that, though: every permission is enforced server-side; a hidden button is just politeness.
6. Restrict groups and boards on top
Roles apply workspace-wide. If someone should see only a single project, combine them with two tools: restricted groups (access per person or team, as view or edit) and private boards (invited people only). Important: the restriction wins. Whoever may only view in a restricted group changes nothing there, no matter how strong their workspace role is.
Troubleshooting
- Someone cannot see the Administration menu item. Access requires the owner role or a management permission: a plain team member does not see it.
- A permission does not take effect. Check all three layers: does the plan include the feature at all? Does the role hold the key? And is the person capped to view in the group or on the board?
- A protected key cannot be ticked. Roles carrying the six protected permissions can only be built and assigned by the owner tier.
- The Superadmin role cannot be edited. By design: it is the role that is guaranteed never to be locked out.
Next steps
- Invite your team and set roles: the roles in everyday use.
- Run a planning poker session: what
poker.moderatemeans in practice. - GDPR-compliant project management, the bigger picture: hosting, DPA and access control.
FAQ
What can a guest do by default?
Nothing actively: the Guest role starts with not a single permission. Guests see what is visible to them but create and change nothing. Since the role is editable, you can grant it individual keys deliberately.
Can I give someone just a single board?
Yes. Make the group a restricted group and grant access per person as view or edit, or make the board private and invite only that person. Both win over the workspace role.
Who may start and close sprints?
By default the Admin role, and the owner role in any case. Through a custom role you can grant the sprint keys without admin rights. The sprint features themselves belong to the Developer plan.
Can I see what someone changed?
At card level yes: through the board activity. Workspace-wide actions such as role or security changes land in the security audit log. That log is deliberately lean: the last 100 events, with no export.
Does this cost extra?
No. The four built-in roles, the permission grid and custom roles are included on every plan (including the free Private Free plan).