Roles & permissions
Per-board roles, a custom role matrix and the audit log.
Permissions are managed per board. Alongside built-in roles (admin, developer, tester, viewer) you can define your own custom roles and mark, in a matrix, which actions each role can perform.
Permission actions
- canMoveTask: move tasks
- canEditWorkflow: edit the workflow
- canStartSprint: start sprints
- canDeleteTask: delete tasks
- canManageMembers: manage members
- canManageCustomFields: manage custom fields / issue types / versions
- canEditTransitions: edit transitions (including a transition’s role requirement)
- canRequestApproval: request approval
- canDecideApproval: approve / reject
- canEditPages: edit docs pages
- canCommentPages: comment on docs pages
On docs-space boards the last two actions determine page access level: canEditPages → edit, canCommentPages → comment only, neither → read only. The built-in roles (Editor, Commenter, Viewer) ship with this mapping.
Group membership on a board
You can add a group to a board instead of a person (Board settings → Members → Groups). Add the group with a role and all its members get access; whoever joins the group later gains access automatically, whoever leaves loses it. No need to edit boards one by one.
- If someone is both a direct member and a member through a group, the broader permission wins
- If a group is the only source of board administration it cannot be removed; assign another admin first
- Adding, removing and role changes of groups are written to the audit log
Audit log
All critical events (role, version, field, membership changes, etc.) are recorded in the audit log as who-what-when. The log is filterable and exportable; it serves as evidence in compliance audits.
