What's new

Plane's roles and permissions system has been rebuilt around a layered access control model. Role-based access control (RBAC) remains the default for every workspace. A new capability called Granular Access Control (GAC) extends RBAC for Enterprise customers, unlocking custom roles composed of reusable permission schemes.

Three system roles have been renamed for clarity, a new Workspace Admin role sits between Owner and Member on Business and Enterprise plans, and conditional permission grants now let a single role express rules like "delete only what you created." Existing role assignments are mapped automatically. No action is required from administrators.

For the complete conceptual reference, see the Roles and permissions overview in our docs.

The two-part access control model

Role-Based Access Control (RBAC) The default model in every Plane workspace. Every user holds a role at the workspace and project level, and that role carries a defined set of permissions. System roles ship on every plan: Workspace Owner, Workspace Admin, Member, Guest, Project Admin, Contributor, Commenter, and project-level Guest.

Granular Access Control (GAC) The Enterprise capability that unlocks custom roles. Instead of being limited to system-defined roles, Enterprise customers build their own roles by composing one or more permission schemes. The effective permissions of a role are the union of every scheme attached to it.

This design lets administrators build roles by combining focused, reusable scheme bundles instead of ticking hundreds of individual checkboxes for every role.

See Create custom roles and Create permission schemes for setup guides.

Scope hierarchy

Plane's permission system operates at three scopes: workspace, project, and teamspace.

Workspace
  ├── Project
  │     ├── Work items, Epics, Modules, Cycles
  │     ├── Pages, Views, Intake
  │     └── Labels, States, Estimates, ...
  ├── Teamspace (grants access to linked projects)
  ├── Wiki, Initiatives, Releases, Dashboards
  └── Integrations, Webhooks, Analytics, ...

Permissions inherit upward. A user with Admin on a project has access to everything inside that project. A user with Owner or Admin on the workspace has access to every project and its content, whether or not they hold an explicit project membership.

New Workspace Admin role

A new Workspace Admin role sits between Workspace Owner and Workspace Member on Business and Enterprise plans. Workspace Admins manage members, billing, integrations, and projects across the workspace. They cannot transfer workspace ownership or delete the workspace itself.

Available on Business and Enterprise.

Custom roles and permission schemes

Custom roles let Enterprise administrators define exactly what a role can and cannot do, without being constrained to system-defined sets.

Roles are what you assign to users. Permission schemes are named bundles of permissions that roles are built from.

System roles each use a single matching scheme. The "Workspace Owner" role, for example, uses the "Workspace Owner" scheme. Custom roles can compose from one scheme or several. Update a scheme once and every role using it picks up the change.

Example custom roles you might build:

• A "Release Manager" that can publish but cannot delete.
• A "QA Reviewer" that can comment and edit but cannot create.
• A "Read-Only Auditor" scoped to specific resource types.

Available on Enterprise.

Conditional permissions

Some permissions only apply when a condition is met. Two conditions ship in this release:

• Creator (+creator): the user must have created the resource. A Contributor with workitem:delete+creator can delete the work items they created, but not work items created by others.
• Lead (+lead): the user must be the lead of the teamspace. A teamspace Member with teamspace:edit+lead can change settings only on teamspaces they lead.

When both an unconditional and a conditional grant apply to the same action, the unconditional grant always wins. If a user holds both workitem:delete and workitem:delete+creator, they can delete any work item, and the condition becomes irrelevant.

Renames and automatic migration

Three roles have been renamed for clarity. Existing assignments map automatically.

A note on Workspace Admin. The role previously called Workspace Admin is now Workspace Owner. A new role also called Workspace Admin has been introduced one level below Owner on Business and Enterprise. They are not the same role. Anyone who held Workspace Admin before this release is now a Workspace Owner. No one has been downgraded.

A note on Commenter. The Commenter role gives view access to project content plus the ability to add comments. It replaces the project-level toggle that previously sat on Guests for view access.

How permission checks resolve

When a user attempts an action, Plane evaluates access in a fixed order, starting at the most specific scope and walking upward.

1. Role permissions on the current scope. An unconditional match grants access. A conditional match grants access if the condition is satisfied.
2. Link relations. Does the user have access via a teamspace linked to this project?
3. Inherit from parent scope. Repeat the same checks one level up (project to workspace).
4. Default deny. If nothing matched after walking the full chain, the action is denied.

A few worked examples make this concrete.

• Bob (Contributor) tries to edit a work item. The system finds Bob's Contributor role on the project, sees workitem:edit is granted unconditionally, and allows the edit.
• Carol (Contributor) tries to delete a module. Contributor has module:delete+creator. The system checks whether Carol created the module. If yes, allowed. If no, denied.
• Dave (Workspace Admin, no project membership) tries to view a work item. No project-level grant exists for Dave. The system walks up to the workspace, finds Dave's Workspace Admin role with wildcard access to project resource types, and allows the view.

Auto-join role mapping

When a workspace member joins a public project, their project role is derived from their workspace role.

Teamspace link relations

A teamspace can be linked to one or more projects. The link carries a role, and every teamspace member receives 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 cannot be assigned high-privilege project roles. When you add a workspace Guest to a project, the only assignable roles are Guest or Commenter. Attempting to assign Admin, Contributor, or any custom project role returns an error. This prevents privilege escalation through project assignment.

Caching and propagation timing

Permission decisions are cached per user for 5 minutes. 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, and the user's next request fetches fresh permissions.

Audit trail (coming soon)

Every permission change will be logged with the actor, the subject, the affected resource, the role before and after the change, and a timestamp. Role definition changes will be tracked field by field, so workspace admins can see exactly which permission was added or removed and by whom.

The audit trail will be available to workspace admins for compliance reporting and access troubleshooting.

Plan availability

Further reading

• Roles and permissions overview
• Permissions matrix
• Member roles
• Create custom roles
• Create permission schemes
• Manage workspace members
• Manage project members