Create custom roles and permissions

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.manageRoles permission.
• 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.edit and its siblings) but without member or workspace management.
• Moderating poker: poker.moderate for the person running the estimation rounds; voters only need poker.join.

To be honest about the mechanics: the role decides who may operate a feature — 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.moderate means in practice.
• GDPR-compliant project management — the bigger picture: hosting, DPA and access control.