Roles and permissions
Plane uses a layered access control system to determine what every user can see and do. This page explains how that system works conceptually so you can design role assignments confidently and troubleshoot access issues when they come up.
If you're looking for what a specific role can or can't do, see the Permissions matrix. If you want a list of system roles, see Member roles. If you want to perform a task, see the how-to guides linked at the bottom of this page.
Two layers: RBAC and GAC
Plane combines two access control models.
Role-Based Access Control (RBAC) is the foundation. Every user holds a role — Owner, Admin, Member, Guest, Contributor, Commenter, or a custom role you've defined — and that role carries a defined set of permissions.
Granular Access Control (GAC) sits on top. It lets you grant or deny specific permissions to specific users on specific resources, independent of their role. A Member could be denied "delete work items" on one particular project, or a Guest could be granted "edit" on a specific page. GAC is for the exceptions — situations where role-level access is too coarse.
Scope hierarchy
Plane's permission system operates at three scopes:
Workspace
├── Project
│ ├── Work items, Epics, Modules, Cycles
│ ├── Pages, Views, Intake
│ └── Labels, States, Estimates, ...
├── Teamspace ──(grants access to)──► Project
├── Wiki, Initiatives, Releases, Dashboards
└── Integrations, Webhooks, Analytics, ...Permissions inherit upward. If a user has Admin on a project, they have access to everything inside that project. If a user has Admin on the workspace, they have access to all projects and their content via wildcard grants.
Plan availability
Different roles and capabilities are available on different plans.
| Capability | Free | Pro | Business | Enterprise |
|---|---|---|---|---|
| Workspace Admin, Member, Guest | ✓ | ✓ | ✓ | ✓ |
| Project Admin, Contributor, Commenter, Guest | ✓ | ✓ | ✓ | ✓ |
| Workspace Owner role | — | — | ✓ | ✓ |
| Custom roles | — | — | — | ✓ |
| Custom permission schemes | — | — | — | ✓ |
On Free and Pro, Admin is the highest workspace role. From Business onwards, Owner sits above Admin and is the only role that can delete the workspace or transfer ownership.
What changed from earlier versions
Two things were renamed or restructured rather than added:
- "Project Member" is now called "Contributor." The role name changed; the permissions did not.
- "Guest view access to Guests" is now the Commenter role. Previously, you toggled "Grant guest users view access to all the project work items" on a Guest. Now, instead of toggling, you assign the user the Commenter role. The role gives view access to project content plus the ability to add comments.
If you've used Plane before, your existing assignments are mapped automatically — no action required.
Roles, schemes, and how they fit together
A role is what you assign to a user. A permission scheme is a named bundle of permissions that a role is built from.
System roles ship with a single matching scheme — for example, the "Workspace Owner" role uses the "Workspace Owner" scheme. Custom roles can compose from one scheme or several. The role's effective permissions are the union of all schemes attached to it.
This design exists so admins can build roles by combining focused, reusable scheme bundles rather than ticking hundreds of individual checkboxes for every role.
Conditional grants
Some permissions only apply when a condition is met. The two conditions used in Plane are:
- +creator — the user must have created the resource. A Contributor can delete work items they created, but not work items created by others.
- +lead — the user must be the lead of the teamspace. A teamspace Member can edit teamspace settings only if they're the lead.
When permissions combine, an unconditional grant always wins over a conditional one. If a user holds both workitem:delete and workitem:delete+creator, they can delete any work item — the unconditional grant takes effect and the condition is irrelevant.
How permission checks work
When a user attempts an action, the system evaluates access in a fixed order, starting at the most specific scope and walking upward.
- Explicit DENY on this exact resource → access denied.
- Explicit GRANT on this exact resource → access allowed.
- Role permissions on this scope:
- Unconditional match → allowed.
- Conditional match → check the condition (creator, lead). If it's satisfied, allowed.
- Link relations — does the user have access via a Teamspace linked to this project?
- Inherit from parent scope — repeat the same checks one level up (project → workspace).
- If nothing matched after walking the full chain → denied by default.
A few worked examples make this concrete.
Can Bob edit Issue #123? Bob has the Contributor role on the project. The system finds no per-resource grant on the issue, walks up to the project, finds Bob's Contributor role, sees that Contributor includes workitem:edit, and allows the edit.
Can Carol delete Module #456? Carol has the Contributor role on the project. Contributor has module:delete+creator. The system checks whether Carol created the module — if yes, allowed; if no, denied.
Can Dave (a workspace Admin with no project membership) view Issue #789? No project-level grant exists for Dave. The system walks up to the workspace, finds Dave's Admin role, which includes wildcard access to all project resource types, and allows the view.
How workspace, project, and teamspace roles interact
Permissions check from the most specific scope upward, which means workspace-level roles can grant project-level access without an explicit project membership.
Workspace Owners and Admins have wildcard grants over all project resource types. They can access any project's content without being added to it explicitly. Removing a workspace Owner or Admin from a project has no functional effect — their workspace role still grants access via inheritance.
Auto-join role mapping. When a workspace member joins a public project, their project role is derived from their workspace role:
| Workspace role | → Project role |
|---|---|
| Owner | Admin |
| Admin | Admin |
| Member or custom role | Contributor |
| Guest | Guest |
Teamspace → project link relations. A teamspace can be linked to one or more projects, and the link carries a role. All teamspace members get that role on the linked project without a separate project membership being created. A user can have both a direct project membership and teamspace-derived access — both are evaluated, and access resolves to whichever permits the action.
Guest ceiling. Workspace Guests are restricted from receiving high-privilege project roles. When you add a workspace Guest to a project, you can only assign them the Guest or Commenter role. Attempting to assign Admin or Contributor returns an error. This prevents privilege escalation through project assignment.
Caching and timing
Permission decisions are cached per user for 5 minutes, and role definitions are cached for 24 hours. When an admin changes a user's role or modifies a role definition, the relevant caches are invalidated immediately. The user's next request fetches fresh permissions.
Effective propagation is near-instant.
Audit trail (coming soon)
Every permission change is logged with the actor, the subject, the affected resource, the role before and after the change, and a timestamp. Role definition changes are tracked field by field, so you can see exactly which permission was added or removed and by whom.
This audit trail is available to workspace admins for compliance reporting and access troubleshooting.
Where to go next
- For lookups about what a specific role can do, see the Permissions matrix.
- For the system role catalog, see Member roles.
- To add and manage workspace members, see Manage workspace members.
- To add and manage project members, see Manage project members.
- To create custom roles, see Create custom roles.
- To build reusable permission bundles, see Create permission schemes.