Two layers of roles #
Account roles are global and control access to administration:
| Role | Can |
|---|---|
user | Use the product within their organizations. |
admin | Manage organizations, users, invitations, roles and webhooks under Admin. |
superadmin | Everything, plus the system area: job queue, schedules, project templates, devices. |
Organization roles are assigned per membership and differ between your internal org and client orgs:
| Organization | Roles |
|---|---|
| Internal | org.superadmin · org.admin · org.staff |
| Client | org.agent · org.client · org.member |
The permission matrix #
Every action maps to one of 28 permissions. A slice of the default matrix:
| Permission | Org superadmin | Org admin | Staff | Agent | Client |
|---|---|---|---|---|---|
tasks.create | ✓ | ✓ | ✓ | — | — |
tasks.delete | ✓ | ✓ | — | — | — |
tickets.create | ✓ | ✓ | ✓ | ✓ | ✓ |
tickets.triage | ✓ | ✓ | ✓ | ✓ | — |
projects.manage | ✓ | ✓ | — | — | — |
members.invite | ✓ | ✓ | — | — | — |
wiki.edit | ✓ | ✓ | ✓ | — | — |
org.manage | ✓ | — | — | — | — |
Admins can review the full matrix under Admin → Roles.
Project membership #
Access to a project is granted by project membership, on top of the organization role. A project has a lead and members with a project role. Staff only see the projects they are members of unless their org role grants everything.
Capabilities #
When a client signs in, the API returns a capability manifest: which surfaces are enabled (tasks, tickets, wiki, chat, notes), what can be created quickly, and the permission map per organization and project. The web app, CLI and iOS app use it to show only what the user can do.