diff --git a/docs/.vitepress/config.ts b/docs/.vitepress/config.ts index 5dd0e689..50b55db7 100644 --- a/docs/.vitepress/config.ts +++ b/docs/.vitepress/config.ts @@ -270,6 +270,10 @@ export default defineConfig({ text: "Manage workspace", link: "/core-concepts/workspaces/overview", }, + { + text: "Manage members", + link: "/core-concepts/workspaces/members", + }, { text: "Search workspace", link: "/workspaces-and-users/search-workspace", @@ -282,21 +286,31 @@ export default defineConfig({ }, ], }, + /* { - text: "Members", + text: "Roles and permissions", collapsed: true, + link: "/roles-and-permissions/overview", items: [ { - text: "Manage members", - link: "/core-concepts/workspaces/members", + text: "Member roles", + link: "/roles-and-permissions/member-roles", + }, + { + text: "Permission schemes", + link: "/roles-and-permissions/permission-schemes", + }, + { + text: "Custom roles", + link: "/roles-and-permissions/custom-roles", }, - { text: "Member roles", link: "/workspaces-and-users/roles" }, { text: "Permissions matrix", - link: "/workspaces-and-users/permissions", + link: "/roles-and-permissions/permissions-matrix", }, ], }, + */ { text: "Authentication", collapsed: true, diff --git a/docs/core-concepts/projects/manage-project-members.md b/docs/core-concepts/projects/manage-project-members.md index 5345f730..7b839165 100644 --- a/docs/core-concepts/projects/manage-project-members.md +++ b/docs/core-concepts/projects/manage-project-members.md @@ -1,16 +1,18 @@ --- title: Manage project members -description: Add members to projects, assign roles, and configure access +description: Add members to projects, assign roles, configure default assignee and project lead, manage subscribers, and understand how teamspace memberships interact with direct project access. --- -# Manage members +# Manage project members Manage who has access to your project and what they can do by adding members and assigning roles. +For background on the available roles, see [Member roles](/roles-and-permissions/member-roles). + **Prerequisites:** -- You must be a Project Admin or Workspace Admin to manage project members -- Users must be workspace members before they can be added to projects +- You must be a Project Admin or Workspace Admin to manage project members. +- Users must be workspace members before they can be added to projects. ## Add members to a project @@ -29,27 +31,37 @@ Users must be workspace members before you can add them to a project. 2. Scroll to the **Members** section. 3. Click **Add member**. 4. Search for and select the workspace member. -5. Assign their role: **Admin**, **Member**, or **Guest**. +5. Assign their role: **Admin**, **Contributor**, **Commenter**, or **Guest**. 6. Click **Add**. The member now has access to the project with the permissions defined by their role. -**Project roles:** +### Project roles + +- **Admin** — Full project access including settings, member management, and all features. +- **Contributor** — Can create and manage work items, epics, cycles, modules, pages, and views. Can delete content they created themselves. +- **Commenter** — Can view all work items in the project and add comments and reactions. Can also create intake submissions. +- **Guest** — Limited access. Can submit intake forms and view, edit, and delete intake issues they created. + +::: info Renamed roles +The role previously called **Member** is now called **Contributor**. Permissions are unchanged. +The previous **Guest view access** toggle has been replaced by the **Commenter** role. To grant view access plus commenting, assign the Commenter role. +::: + +See [Permissions matrix](/roles-and-permissions/permissions-matrix) for the complete breakdown. -- **Admin** - Full project access including settings, member management, and all features. -- **Member** - Can create and manage work items, cycles, and modules (cannot change project settings). -- **Guest** - Limited view access (cannot create or edit). +### Workspace Guest restriction -See [Member roles](/workspaces-and-users/roles) for complete role permissions. +If you're adding a workspace Guest to your project, you can only assign them the **Guest** or **Commenter** role. Attempting to assign Admin or Contributor returns an error. This guardrail prevents external collaborators from being accidentally over-privileged. ## Change a project member's role Update project member roles as responsibilities change. -1. Navigate to **Project Settings > Members & Teamspaces** -2. Find the member in the **Members** list -3. Click the **Role** dropdown next to their name -4. Select the new role (Admin, Member, or Guest) +1. Navigate to **Project Settings > Members & Teamspaces**. +2. Find the member in the **Members** list. +3. Click the **Role** dropdown next to their name. +4. Select the new role. The role change takes effect immediately. @@ -66,19 +78,23 @@ The member loses access to the project immediately but remains in the workspace. **What happens when you remove a member:** -- They can no longer access the project or its work items -- Work items they created remain in the project -- Their comments and activity history are preserved -- They remain a workspace member (unless removed separately) +- They can no longer access the project or its work items. +- Work items they created remain in the project. +- Their comments and activity history are preserved. +- They remain a workspace member (unless removed separately). + +::: info Removing workspace Owners and Admins +Removing a workspace Owner or Admin from a project removes the project membership record but does not restrict their access — they retain access to all project content via their workspace role. +::: ## Default assignee Configure a default assignee to ensure all work items get assigned when created without an explicit assignee. -1. Navigate to **Project Settings > Members & Teamspaces** -2. Find the **Default Assignee** setting -3. Click the dropdown and select a project member -4. The setting saves automatically +1. Navigate to **Project Settings > Members & Teamspaces**. +2. Find the **Default Assignee** setting. +3. Click the dropdown and select a project member. +4. The setting saves automatically. **How default assignee works:** @@ -107,7 +123,7 @@ The project lead is the go-to person for questions about the project's execution - Project Admin is a role with specific permissions. - They can be the same person but don't have to be. -## Project subscribers +## Project subscribers Project subscribers receive notifications for all work items in the project — status changes, comments, and updates. This is useful for project leads, managers, or stakeholders who need visibility across the entire project without being subscribed to individual work items. @@ -123,18 +139,6 @@ To configure project subscribers: Only project admins can manage project subscribers. -## Grant view access to Guests - -By default, Guests can only see work items they've created through the Intake section. You can expand their visibility to all project work items. - -1. Navigate to **Project Settings > Members & Teamspaces**. -2. Find the **Guest access** setting. -3. Toggle on **Grant guest users view access to all the project work items**. - -![Grant guest users view access](https://media.docs.plane.so/workspaces/grant-guests-view-access.webp#hero-tr) - -This setting is project-specific. Enabling it in one project doesn't affect Guest permissions in other projects. Even with view access, Guests remain isolated to invited projects only. - ## View project member activity ::: info @@ -150,34 +154,39 @@ Track member actions like additions, role changes, and removals to maintain visi The activity panel shows recent project member events: -- **Member additions** - Who added which members to the project and when. -- **Role changes** - Role updates with who made the change and when. -- **Member removals** - Who removed members from the project. - -Each activity entry shows: +- **Member additions** — who added which members to the project and when. +- **Role changes** — role updates with who made the change and when. +- **Member removals** — who removed members from the project. -- The action taken -- Who performed the action -- When it happened (relative time like "6 days ago" or "3 days ago") +Each activity entry shows the action taken, who performed the action, and when it happened (relative time like "6 days ago" or "3 days ago"). This audit trail helps project admins monitor membership changes and verify that access permissions are correct. Activity is retained for project history. ## Leave a project -If you no longer need access to a project, you can leave it yourself. Click the … menu next to your own name in Project Settings > Members & Teamspaces and select Leave. +If you no longer need access to a project, you can leave it yourself. Click the … menu next to your own name in **Project Settings > Members & Teamspaces** and select **Leave**. You'll lose access to the project immediately but remain in the workspace. If you need to rejoin later, a Project Admin or Workspace Admin will need to add you again. +::: warning Last admin protection +If you're the only Project Admin, you cannot leave the project. Promote another member to Admin first. +::: + ## How users join projects Users can become project members in two different ways, and understanding both helps you manage your project team effectively. -**Direct project membership** is where you specifically invite users to your project and assign them roles. These members have access only to the projects you've added them to, and you have full control over their permissions. +**Direct project membership** is when you specifically invite users to your project and assign them roles. These members have access only to the projects you've added them to, and you have full control over their permissions. + +**Teamspace-based membership** happens automatically when your project is linked to a [Teamspace](/core-concepts/workspaces/teamspaces). All members of that teamspace automatically receive the role assigned on the teamspace-to-project link, making it ideal for teams that collaborate across multiple projects. -**Teamspace-based membership** happens automatically when your project is linked to a [Teamspace](/core-concepts/workspaces/teamspaces). All members of that teamspace automatically receive `Member` access to your project, making it perfect for teams that collaborate across multiple projects. +Users can have both types of access simultaneously. When this happens, Plane evaluates both grants — direct membership is checked first, and either source can grant the access. -Users can have both types of access simultaneously. When this happens, Plane automatically applies whichever role gives them higher permissions. For example, if someone is a `Guest` on your project but joins a linked teamspace, they're automatically upgraded to `Member` access. If they're already an `Admin`, they keep their `Admin` role. +For example, if someone is a `Guest` on your project but joins a linked teamspace whose link grants `Contributor` access, they get Contributor access to the project through the teamspace. If they're already an `Admin`, they keep their `Admin` role through their direct membership. ## See also - [Manage workspace members](/core-concepts/workspaces/members) +- [Member roles](/roles-and-permissions/member-roles) +- [Permissions matrix](/roles-and-permissions/permissions-matrix) +- [Teamspaces](/core-concepts/workspaces/teamspaces) diff --git a/docs/core-concepts/workspaces/members.md b/docs/core-concepts/workspaces/members.md index 467b27fb..d941273c 100644 --- a/docs/core-concepts/workspaces/members.md +++ b/docs/core-concepts/workspaces/members.md @@ -3,11 +3,13 @@ title: Manage workspace members description: Add, update, and remove workspace members --- -# Manage members +# Manage workspace members -Keeping your workspace organized and secure is essential for smooth project management. Plane makes it easy to control who can access your workspace, what they can do, and how they collaborate with others. +Manage who can access your workspace and what they can do. -This guide shows you how to add members to your workspace, change their roles, and remove them when needed. +This guide covers inviting members, importing them in bulk, changing roles, removing members, and viewing audit history. + +For background on the available roles, see [Member roles](/roles-and-permissions/member-roles). ## Invite members to your workspace @@ -19,7 +21,7 @@ You can add members individually or in bulk using CSV import. 2. Click **Add member**. 3. In the modal: - Enter the email address of the person you're inviting. - - Select their role: **Admin**, **Member**, or **Guest**. + - Select their role. - To invite multiple people at once, click **Add another** and repeat. 4. Click **Invite**. @@ -57,16 +59,21 @@ Email, Display Name, First Name, Last Name, Role ``` Email,Display Name,First Name,Last Name,Role -alex@company.com,Alex Chen,Alex,Chen,15 -sarah@company.com,Sarah Kim,Sarah,Kim,20 -mike@company.com,Mike Rodriguez,Mike,Rodriguez,5 +alex@company.com,Alex Chen,Alex,Chen,member +sarah@company.com,Sarah Kim,Sarah,Kim,admin +mike@company.com,Mike Rodriguez,Mike,Rodriguez,guest ``` -**Role values:** +**Valid roles:** + +- `owner` — Workspace Owner +- `admin` — Workspace Admin +- `member` — Workspace Member +- `guest` — Workspace Guest -- `5` – Guest -- `15` – Member -- `20` – Admin +::: info Backward compatibility +For backward compatibility, numeric role values still work: `5` for Guest, `15` for Member, `20` for Admin. We recommend using slugs. +::: **Important notes** @@ -130,9 +137,16 @@ Removing members doesn't change your seat count or billing. You must [remove sea ## Leave a workspace -If you no longer need access to a workspace, you can leave it yourself. Click the … menu next to your own name in Workspace Settings > Members and select **Leave**. -You'll lose access to the workspace and all its projects immediately. If you need to rejoin later, a Workspace Admin will need to invite you again. +If you no longer need access to a workspace, you can leave it yourself. Click the … menu next to your own name in **Workspace Settings > Members** and select **Leave**. + +You'll lose access to the workspace and all its projects immediately. If you need to rejoin later, a Workspace Admin or Owner will need to invite you again. + +::: warning Last admin protection +If you're the only Owner or Admin in the workspace, you cannot leave. Promote another user to Owner or Admin first. +::: ## See also +- [Member roles](/roles-and-permissions/member-roles) - [Manage project members](/core-concepts/projects/manage-project-members) +- [Permissions matrix](/roles-and-permissions/permissions-matrix) diff --git a/docs/core-concepts/workspaces/overview.md b/docs/core-concepts/workspaces/overview.md index 94924907..7ca9da75 100644 --- a/docs/core-concepts/workspaces/overview.md +++ b/docs/core-concepts/workspaces/overview.md @@ -16,7 +16,7 @@ Every workspace in Plane has two main components: - **Projects** Projects serve as the cornerstone for all activities within the product. You can create work items, assign tasks to members, and track progress for whatever you’re working on. If you envision your organization as NASA, each mission can be likened to a project. [Learn more here](/core-concepts/projects/overview). - **Members** - Invite your teammates, collaborators, or managers to join your workspace. Each user gets a role, like Admin, Member, or Guest, to control what they can do. [Explore roles here](/workspaces-and-users/roles). + Invite your teammates, collaborators, or managers to join your workspace. Each user gets a role, like Admin, Member, or Guest, to control what they can do. [Explore roles here](/roles-and-permissions/member-roles). ## Create workspace diff --git a/docs/introduction/tutorials/invite-members.md b/docs/introduction/tutorials/invite-members.md index 8efc3ba4..40cb83d6 100644 --- a/docs/introduction/tutorials/invite-members.md +++ b/docs/introduction/tutorials/invite-members.md @@ -69,7 +69,7 @@ For each person you're inviting, select their role from the dropdown. - Best for external contractors, clients, temporary collaborators. ::: tip -💡 Want a deeper breakdown? Check out the [full guide](/workspaces-and-users/permissions) on roles and permissions. +💡 Want a deeper breakdown? Check out the [full guide](/roles-and-permissions/permissions-matrix) on roles and permissions. ::: ## Send invitations diff --git a/docs/roles-and-permissions/custom-roles.md b/docs/roles-and-permissions/custom-roles.md new file mode 100644 index 00000000..a7b9121d --- /dev/null +++ b/docs/roles-and-permissions/custom-roles.md @@ -0,0 +1,97 @@ +--- +title: Custom roles +description: Create custom workspace and project roles tailored to your organization. Compose roles from permission schemes, base them on system roles, and assign them to members. +--- + +# Custom roles + +Custom roles let you define exactly what users in your workspace can do. + +Build a "Release Manager" role that can publish but not delete, a "QA Reviewer" who can comment and edit but not create, or anything else your organization needs. + +For background, see [Roles and permissions](/roles-and-permissions/overview). To understand permission schemes (the building blocks of custom roles), see [Create permission schemes](/roles-and-permissions/permission-schemes). + +![Custom roles](https://media.docs.plane.so/roles-and-permissions/workspace-custom-role.webp#hero) + +## Create a custom workspace role + +Custom workspace roles control access to workspace-level resources — settings, members, integrations, the wiki, and more. + +1. Navigate to **Workspace settings > Roles and permissions schemes > Workspace**. +2. Click the **Roles** tab. +3. Click **Create Role** in the top right. +4. In the **Create new role** modal: + - Enter a **Role title** (e.g., "Billing Administrator"). + - Add an optional **Description** to clarify the role's purpose. +5. Click **Create role**. + +The role is created with no permissions attached. You'll be taken to the role's detail page where you can attach permission schemes. + +## Create a custom project role + +Custom project roles control access within projects. + +1. Navigate to **Workspace settings > Roles and permissions schemes > Project** +2. Click the **Roles** tab. +3. Click **Create Role**. +4. Enter the **Role title** and **Description**. +5. Click **Create role**. + +## Attach permission schemes to a role + +A role's effective permissions are the combined set of all schemes attached to it. + +1. Open the role from the **Roles** tab. +2. In the **Permissions Schemes** section, click **Attach Permissions Schemes**. +3. Select one or more schemes from the right-hand panel: + - System schemes (e.g., **Workspace Member**, **Workspace Admin**, **Project Contributor**) come pre-built and cannot be modified. + - Custom schemes can be created and edited — see [Create permission schemes](/roles-and-permissions/permission-schemes). +4. Click **Add**. + +The role now has all permissions from the selected schemes. If a scheme grants `workitem:edit` and another scheme grants `workitem:edit+creator`, the unconditional permission wins — the role can edit any work item. + +## Edit a custom role + +1. Navigate to **Workspace settings > Workspace** or **Project** under **Roles And Permissions Schemes**. +2. Click the **…** menu next to the role. +3. Select **Edit role**. +4. Update the title, description, or attached permission schemes. + +Changes take effect immediately for all members assigned the role. + +## Delete a custom role + +1. Click the **…** menu next to the role. +2. Select **Delete role**. +3. If members are assigned the role, you'll be prompted to choose a replacement role. All affected members will be reassigned to the replacement. +4. Confirm. + +::: warning System roles can't be deleted +System roles (Owner, Admin, Member, Guest, Contributor, Commenter) cannot be deleted. +::: + +## Constraints on custom roles + +A few rules govern what custom roles can and cannot do: + +- **Cannot include reserved permissions.** Custom roles cannot grant **Delete Workspace**, **Transfer Ownership**, or full access. These are reserved for the Owner role. +- **Workspace-scoped.** Custom roles are defined per workspace. They don't propagate to other workspaces. +- **Counted as paid seats.** Members assigned custom roles count as paid seats for billing. + +## Base a custom role on a system role + +A common pattern is to create a custom role that's "system role X plus extra permissions." For example, a "Senior Contributor" role that has all Contributor permissions plus the ability to manage labels and states. + +1. Create the new role with a title and description. +2. Attach the system permission scheme (e.g., **Project Contributor**) to inherit those permissions. +3. Create or attach a custom scheme that adds the extra permissions you want. + +::: info +The custom role inherits the system scheme's permissions at the moment of attachment. If the system scheme changes later, your custom role automatically reflects the changes (since it references the same scheme). +::: + +## See also + +- [Create permission schemes](/roles-and-permissions/permission-schemes) +- [Roles and permissions](/roles-and-permissions/overview) +- [Permissions matrix](/roles-and-permissions/permissions-matrix) diff --git a/docs/roles-and-permissions/member-roles.md b/docs/roles-and-permissions/member-roles.md new file mode 100644 index 00000000..9b7d7dd3 --- /dev/null +++ b/docs/roles-and-permissions/member-roles.md @@ -0,0 +1,144 @@ +--- +title: Member roles +description: Reference for every system role in Plane — Owner, Admin, Member, Guest at the workspace level, and Admin, Contributor, Commenter, Guest at the project level. Includes plan availability, role slugs, and guidance on when to use each. +--- + +# Member roles + +Every user in Plane holds a role at the workspace level and, for each project they're added to, a role at the project level. This page is a reference for all system roles and what they're for. + +For the conceptual background, see [Roles and permissions](/roles-and-permissions/overview). For exhaustive permission breakdowns, see the [Permissions matrix](/roles-and-permissions/permissions-matrix). + +## Workspace roles + +Workspace roles control access to workspace-level resources — settings, members, billing, integrations, the wiki, workspace views, initiatives, and the project list. They also determine what a user can do across the projects they're added to. + +### Owner + +Owner is the highest workspace role. It carries full access to everything in the workspace, including the two operations no other role can perform: deleting the workspace and transferring ownership to another user. + +Use Owner for the founder or principal administrator of the workspace. Most workspaces only have one Owner. + +::: info Renamed from "Admin" +The role previously called "Admin" at the workspace level is now called "Owner." +::: + +### Admin + +Admin gives full management of the workspace — settings, members, billing, projects, integrations, webhooks, and roles — without the ability to delete the workspace or transfer ownership. + +An Admin can access any project's content without being added as a project member. This is by design: workspace administrators sometimes need to step into a project to fix a misconfiguration or audit work, and forcing them to be added to every project would be impractical. + +Use Admin for technical leads, ops staff, or anyone who needs to administer the workspace without being its principal owner. + +### Member + +Member is the standard role for internal contributors. A Member can view the workspace, browse the project list, create and contribute to wiki pages, create workspace views, view analytics, and use integrations. + +Members do not have access to project content unless they're explicitly added to a project. When they join a public project, they automatically become a Contributor on it. + +Use Member for full-time team members who actively work on projects. + +### Guest + +Guest is the most restricted workspace role. A Guest can only see projects they've been explicitly added to. + +When a workspace Guest is added to a project, they can only be assigned the Guest or Commenter role. They cannot be promoted to Contributor or Admin within a project. This guardrail prevents external collaborators from being accidentally over-privileged. + +Use Guest for clients, contractors, or external stakeholders who need restricted access to specific projects only. + +## Project roles + +Project roles control what a user can do inside a specific project. + +### Project Admin + +Project Admin has full control over the project — settings, members, work items, epics, cycles, modules, pages, views, intake, automations, workflows, labels, states, and estimates. Project Admins can also delete or archive the project itself. + +Use Project Admin for project leads, managers, or anyone responsible for the project's setup and execution. + +### Contributor + +Contributor is the standard project role for people doing the work. Contributors can create and edit work items, epics, modules, cycles, pages, and views. They can delete content they created themselves, but not content created by others. They can add comments, attach files, log work, and add reactions. + +Contributors cannot manage project settings, change member roles, manage labels or states, or delete content created by others. + +::: info Renamed from "Member" +The role previously called "Member" at the project level is now called "Contributor." +::: + +Use Contributor for everyone who actively works on the project's content. + +### Commenter + +Commenter can view all work items and add comments and reactions. They can also create Intake submissions. They cannot create or edit work items, modules, cycles, or pages. + +::: info Replaces "Guest view access" +Previously, a project Guest could be granted view access via a project-level toggle. That toggle no longer exists. To give someone view-only access to work items plus commenting, assign them the Commenter role. +::: + +Use Commenter for stakeholders who need to follow along, leave feedback, and submit intake requests, but shouldn't create or modify work. + +### Guest + +Project Guest is the most restricted project role. They can submit intake forms and view, edit, and delete intake issues they created themselves. They cannot see or create work items in the project. + +Use Guest for external collaborators whose only interaction with the project is submitting requests through intake. + +## Teamspace role + +Teamspaces have a single role, and conditions on the lead determine what each member can do beyond their own content. + +All teamspace members can view the teamspace and its pages, views, and comments. They can create new pages, views, and comments, and they can edit pages collaboratively. Each member can edit and delete their own comments and views. + +Only the **teamspace lead** can edit the teamspace's settings, delete the teamspace, manage its members, or delete content created by other members. + +## When to use each role + +For workspace assignments: + +- **Owner** — the principal owner of the workspace. Reserve for one or two people. +- **Admin** — anyone who needs to manage workspace settings, billing, integrations, members, or roles. +- **Member** — internal contributors who do project work. +- **Guest** — external clients, contractors, or stakeholders with project-specific access only. + +For project assignments: + +- **Admin** — project leads who own the project's setup and execution. +- **Contributor** — anyone actively doing the work. +- **Commenter** — stakeholders who need read access plus the ability to comment and submit intake. +- **Guest** — external collaborators interacting only via intake. + +## Role hierarchy + +Roles have an internal authority level used to enforce who can manage whom. A user can only modify members whose role level is lower than their own. + +- Only Owners can manage other Owners. +- Owners and Admins can manage Admins. +- The last Admin or Owner of a workspace cannot leave or be demoted. +- The last Admin of a project cannot leave. + +## Custom roles + +Workspace owners and admins can create custom roles composed from any combination of permission schemes. Custom roles cannot include workspace deletion or ownership transfer (those are reserved for Owner). + +For details, see [Create custom roles](/roles-and-permissions/custom-roles). + +## Paid seat classification + +Most workspace roles count as paid seats for billing purposes. Workspace Guest is the only role that does not. + +| Role | Counts as paid seat | +| ------------ | ------------------- | +| Owner | Yes | +| Admin | Yes | +| Member | Yes | +| Guest | No | +| Custom roles | Yes | + +## See also + +- [Roles and permissions](/roles-and-permissions/overview) +- [Permissions matrix](/roles-and-permissions/permissions-matrix) +- [Manage workspace members](/core-concepts/workspaces/members) +- [Manage project members](/core-concepts/projects/manage-project-members) diff --git a/docs/roles-and-permissions/overview.md b/docs/roles-and-permissions/overview.md new file mode 100644 index 00000000..56e581f3 --- /dev/null +++ b/docs/roles-and-permissions/overview.md @@ -0,0 +1,131 @@ +--- +title: Roles and permissions +description: Understand how roles, permissions, and access control work in Plane — including system roles, custom roles, conditional grants, and how access is evaluated across workspaces, projects, and teamspaces. +--- + +# 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. + +If you're looking for what a specific role can or can't do, see the [Permissions matrix](/roles-and-permissions/permissions-matrix). If you want a list of system roles, see [Member roles](/roles-and-permissions/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 Contributor could be denied "delete work items" on one particular project while keeping that permission everywhere else, or a specific user could be granted temporary edit access to a single page for the duration of an external review — all without changing anyone's role. 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. + +## Plan availability + +Different roles and capabilities are available on different plans. + +| Capability | Free | Pro | Business | Enterprise | +| -------------------------------------------- | ---- | --- | -------- | ---------- | +| Workspace Owner, Member, Guest | ✓ | ✓ | ✓ | ✓ | +| Project Admin, Contributor, Commenter, Guest | ✓ | ✓ | ✓ | ✓ | +| **Workspace Admin role** | — | — | ✓ | ✓ | +| **Custom roles** | — | — | — | ✓ | +| **Custom permission schemes** | — | — | — | ✓ | + +## What changed from earlier versions + +Three things were renamed or restructured: + +- **"Workspace Admin" is now called "Workspace Owner."** +- **"Project Member" is now called "Contributor."** +- **"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. + +1. **Role permissions** on this scope: + - Unconditional match → allowed. + - Conditional match → check the condition (creator, lead). If it's satisfied, allowed. +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 → workspace). +4. If nothing matched after walking the full chain → **denied by default**. + +A few worked examples make this concrete. + +**Can Bob edit work items** 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 modules?** 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 work items?** 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 — both default and custom project roles beyond these are blocked. Attempting to assign Admin, Contributor, or any custom project role 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. + +## 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](/roles-and-permissions/permissions-matrix). +- For the system role catalog, see [Member roles](/roles-and-permissions/member-roles). +- To add and manage workspace members, see [Manage workspace members](/core-concepts/workspaces/members). +- To add and manage project members, see [Manage project members](/core-concepts/projects/manage-project-members). +- To create custom roles, see [Create custom roles](/roles-and-permissions/custom-roles). +- To build reusable permission bundles, see [Create permission schemes](/roles-and-permissions/permission-schemes). diff --git a/docs/roles-and-permissions/permission-schemes.md b/docs/roles-and-permissions/permission-schemes.md new file mode 100644 index 00000000..5f641b98 --- /dev/null +++ b/docs/roles-and-permissions/permission-schemes.md @@ -0,0 +1,96 @@ +--- +title: Create permission schemes +description: Build reusable permission bundles that can be combined to compose custom roles. Permission schemes group related permissions so you can manage access in modular pieces. +--- + +# Permission schemes + +A **permission scheme** is a named bundle of permissions that you can attach to one or more custom roles. Schemes are the modular building blocks of custom roles — instead of defining every permission individually for each role, you create reusable schemes and combine them. + +For background, see [Roles and permissions](/roles-and-permissions/overview). To create roles that use schemes, see [Create custom roles](/roles-and-permissions/custom-roles). + +## Why use permission schemes + +Permission schemes give you three advantages: + +- **Reuse.** The same scheme can power multiple roles. Update the scheme once, and every role using it picks up the change. +- **Modularity.** Build focused schemes that do one thing well, then combine them. A "Release Manager" role might combine **Project Contributor** + a custom **Release Publishing** scheme. +- **Clarity.** Schemes have descriptive names and clear scopes, making role definitions easier to read and audit. + +![Custom permission schemes](https://media.docs.plane.so/roles-and-permissions/workspace-custom-permission-scheme.webp#hero) + +## Create a workspace permission scheme + +Workspace schemes contain permissions that apply at the workspace level. + +1. Navigate to **Workspace settings > Roles and permissions schemes > Workspace**. +2. Click the **Permission Schemes** tab. +3. Click **Create Permission Scheme** in the top right. +4. In the **Create permission scheme** form: + - **Scheme name** — a short, descriptive name. + - **Description** — optional explanation of the scheme's purpose. +5. In the permissions section, check the boxes for the permissions this scheme should grant. +6. Use **Select All** within a group to enable every permission in that group, or **Search permissions** at the top to find specific permissions. +7. Click **Create permission scheme**. + +The scheme is saved and immediately available to attach to roles. + +## Create a project permission scheme + +Project schemes contain permissions that apply within projects. + +1. Navigate to **Workspace settings > Roles and permissions schemes > Project**. +2. Click the **Permission Schemes** tab. +3. Click **Create Permission Scheme**. +4. Fill in the scheme name and description. +5. Select permissions from the project-level groups. +6. Click **Create permission scheme**. + +## Edit a permission scheme + +1. Navigate to the **Permission Schemes** tab. +2. Click the **…** menu next to the scheme. +3. Select **Edit permission scheme**. +4. Update the name, description, or selected permissions. +5. Save your changes. + +::: warning Changes propagate to roles +Editing a scheme immediately updates the effective permissions of every role that has it attached. Members assigned those roles will have their permissions refreshed on their next request. +::: + +## Delete a permission scheme + +1. Click the **…** menu next to the scheme. +2. Select **Delete permission scheme**. +3. Confirm. + +::: warning Schemes attached to roles +Deleting a scheme removes its permissions from any role using it. If a role had that scheme as its only source of permissions, the role will be left with no effective permissions until you attach another scheme. +::: + +::: info System schemes can't be deleted +System schemes (e.g., **Workspace Owner**, **Workspace Admin**, **Workspace Member**, **Workspace Guest**) are tagged "System" and cannot be edited or deleted. +::: + +## Attach a scheme to a role + +1. Open the role from the **Roles** tab. +2. In the **Permissions Schemes** section, click **Attach Permissions Schemes**. +3. Check the schemes you want to attach. +4. Click **Add**. + +The role's effective permissions become the union of all attached schemes. + +## How permissions combine + +When a role has multiple schemes attached, the effective permission set is the union of all of them. The combination rules are: + +- **Unconditional grants win over conditional ones.** If one scheme grants `workitem:delete` and another grants `workitem:delete+creator`, the role gets unconditional `workitem:delete`. +- **More permissive wins.** If schemes grant the same permission, it's still granted (there's no "negative override" within scheme combinations — that requires GAC). +- **Permission dependencies are auto-managed.** Enabling a permission auto-enables its prerequisites (e.g., enabling Edit auto-enables View). Disabling a prerequisite auto-disables permissions that depend on it. + +## See also + +- [Create custom roles](/roles-and-permissions/custom-roles) +- [Roles and permissions](/roles-and-permissions/overview) +- [Permissions matrix](/roles-and-permissions/permissions-matrix) diff --git a/docs/roles-and-permissions/permissions-matrix.md b/docs/roles-and-permissions/permissions-matrix.md new file mode 100644 index 00000000..cb166b7b --- /dev/null +++ b/docs/roles-and-permissions/permissions-matrix.md @@ -0,0 +1,568 @@ +--- +title: Permissions matrix +description: Complete permissions reference for every role in Plane. Organized by the same permission groups used in the role builder so you can compare exactly what each role can and can't do. +--- + +# Permissions matrix + +This is the exhaustive permissions reference for every system defined role in Plane. + +For conceptual background, see [Roles and permissions](/roles-and-permissions/overview). For the role catalog, see [Member roles](/roles-and-permissions/member-roles). + +## How to read this page + +**Legend** + +- ✓ - the role has unconditional access to this permission. +- **+Creator** - the role can perform the action only on resources they created. +- **+Lead** - the role can perform the action only if they're the teamspace lead. +- x - the role does not have this permission. + +**Owner has full access.** Workspace Owner holds a full-access wildcard and matches every permission in this document. The Owner column is omitted from individual tables and assumed ✓ throughout. + +**Workspace Admin and Owner bypass projects.** Both have wildcard access to every project resource type, so they appear as ✓ on all project-level permissions even without explicit project membership. + +## Workspace permissions + +### Workspace management + +Core workspace configuration: name, logo, currency, domain, archival, deletion, and ownership transfer. + +| Permission | Owner | Admin | Member | Guest | +| ----------------------- | ----- | ----- | ------ | ----- | +| View Workspace | ✓ | ✓ | ✓ | ✓ | +| Edit Workspace Settings | ✓ | ✓ | x | x | +| Manage Workspace | ✓ | ✓ | x | x | +| Invite Members | ✓ | ✓ | x | x | +| Archive Workspace | ✓ | ✓ | x | x | +| Delete Workspace | ✓ | x | x | x | +| Transfer Ownership | ✓ | x | x | x | + +Only Owner can delete the workspace or transfer ownership. + +### Member management + +Inviting, editing, importing, and removing workspace members. + +| Permission | Owner | Admin | Member | Guest | +| -------------------------- | ----- | ----- | ------ | ----- | +| View Members | ✓ | ✓ | ✓ | ✓ | +| Invite Members | ✓ | ✓ | x | x | +| Edit Member Details | ✓ | ✓ | x | x | +| Import Members (CSV / SSO) | ✓ | ✓ | x | x | +| Change Member Role | ✓ | ✓ | x | x | +| Remove Members | ✓ | ✓ | x | x | + +Role hierarchy is enforced. Admins cannot modify members at the same or higher level than their own. + +### Project management + +Creating and managing projects from the workspace context. + +| Permission | Owner | Admin | Member | Guest | +| ------------------------------ | ----- | ----- | ------ | ----- | +| Browse Projects | ✓ | ✓ | ✓ | x | +| View Project Details | ✓ | ✓ | ✓ | x | +| Create Projects | ✓ | ✓ | x | x | +| Edit Project Settings | ✓ | ✓ | x | x | +| Publish Projects (make public) | ✓ | ✓ | x | x | +| Archive Projects | ✓ | ✓ | x | x | +| Delete Projects | ✓ | ✓ | x | x | +| Manage Project Access | ✓ | ✓ | x | x | + +Guests can only see projects they've been explicitly added to. + +### Role administration + +Creating and managing custom roles and project roles. + +| Permission | Owner | Admin | Member | Guest | +| ----------------------- | ----- | ----- | ------ | ----- | +| View Custom Roles | ✓ | ✓ | x | x | +| Create Custom Roles | ✓ | ✓ | x | x | +| Edit Custom Roles | ✓ | ✓ | x | x | +| Delete Custom Roles | ✓ | ✓ | x | x | +| View Project Roles | ✓ | ✓ | x | x | +| Create Project Roles | ✓ | ✓ | x | x | +| Edit Project Roles | ✓ | ✓ | x | x | +| Delete Project Roles | ✓ | ✓ | x | x | +| Define Role Permissions | ✓ | ✓ | x | x | + +Custom roles and permission schemes are an Enterprise feature. + +### Wiki + +Workspace-level wikis. + +| Permission | Owner | Admin | Member | Guest | +| --------------------- | ----- | ----- | ------ | ----- | +| View Wiki | ✓ | ✓ | ✓ | x | +| Create Wiki Pages | ✓ | ✓ | ✓ | x | +| Edit Wiki Pages | ✓ | ✓ | ✓ | x | +| Share Wiki Pages | ✓ | ✓ | ✓ | x | +| Delete Wiki Pages | ✓ | ✓ | ✓ | x | +| Comment on Wiki Pages | ✓ | ✓ | ✓ | x | + +### Workspace Views + +Workspace-level saved filters and view management. + +| Permission | Owner | Admin | Member | Guest | +| ----------------------- | ----- | ----- | -------- | ----- | +| View Workspace Views | ✓ | ✓ | ✓ | ✓ | +| Create Workspace Views | ✓ | ✓ | ✓ | x | +| Edit Workspace Views | ✓ | ✓ | +Creator | x | +| Share Workspace Views | ✓ | ✓ | ✓ | x | +| Publish Workspace Views | ✓ | ✓ | ✓ | x | +| Export Workspace Views | ✓ | ✓ | ✓ | x | +| Delete Workspace Views | ✓ | ✓ | +Creator | x | + +Members can only edit and delete views they created themselves. + +### Initiatives + +Cross-project initiative tracking, including comments, attachments, links, and updates. + +| Permission | Owner | Admin | Member | Guest | +| ----------------------------- | ----- | ----- | -------- | ----- | +| View Initiatives | ✓ | ✓ | ✓ | x | +| Create Initiatives | ✓ | ✓ | x | x | +| Edit Initiatives | ✓ | ✓ | x | x | +| Manage Initiatives | ✓ | ✓ | x | x | +| Delete Initiatives | ✓ | ✓ | x | x | +| Edit Initiative Comments | ✓ | ✓ | +Creator | x | +| Delete Initiative Comments | ✓ | ✓ | +Creator | x | +| Delete Initiative Attachments | ✓ | ✓ | +Creator | x | +| Post Initiative Updates | ✓ | ✓ | ✓ | x | +| Edit Initiative Updates | ✓ | ✓ | ✓ | x | +| Delete Initiative Updates | ✓ | ✓ | ✓ | x | + +### Teamspaces + +Browsing, creating, and managing teamspaces. + +| Permission | Owner | Admin | Member | Guest | +| ------------------------ | ----- | ----- | ------ | ----- | +| Browse Teamspaces | ✓ | ✓ | ✓ | x | +| View Teamspace Details | ✓ | ✓ | ✓ | x | +| Create Teamspaces | ✓ | ✓ | x | x | +| Edit Teamspaces | ✓ | ✓ | +Lead | x | +| Manage Teamspace Members | ✓ | ✓ | +Lead | x | +| Delete Teamspaces | ✓ | ✓ | +Lead | x | + +Editing, deleting, or managing members on a teamspace requires being the teamspace lead. Workspace Admin role alone is not sufficient. + +### Integrations + +Third-party integrations, webhooks, and API tokens. + +| Permission | Owner | Admin | Member | Guest | +| ---------------------- | ----- | ----- | ------ | ----- | +| View Integrations | ✓ | ✓ | ✓ | x | +| Create Integrations | ✓ | ✓ | ✓ | x | +| Configure Integrations | ✓ | ✓ | ✓ | x | +| Delete Integrations | ✓ | ✓ | x | x | +| View Webhooks | ✓ | ✓ | x | x | +| Create Webhooks | ✓ | ✓ | x | x | +| Edit Webhooks | ✓ | ✓ | x | x | +| Delete Webhooks | ✓ | ✓ | x | x | +| View API Tokens | ✓ | ✓ | ✓ | x | +| Create API Tokens | ✓ | ✓ | ✓ | x | +| Delete API Tokens | ✓ | ✓ | ✓ | x | + +### Analytics and reporting + +Dashboards, analytics, and work logs. + +| Permission | Owner | Admin | Member | Guest | +| ----------------- | ----- | ----- | ------ | ----- | +| View Analytics | ✓ | ✓ | ✓ | x | +| Export Analytics | ✓ | ✓ | ✓ | x | +| View Dashboards | ✓ | ✓ | ✓ | x | +| Create Dashboards | ✓ | ✓ | x | x | +| Edit Dashboards | ✓ | ✓ | x | x | +| Delete Dashboards | ✓ | ✓ | x | x | +| View Work Logs | ✓ | ✓ | ✓ | x | +| Export Work Logs | ✓ | ✓ | ✓ | x | +| Use AI Features | ✓ | ✓ | ✓ | x | + +### Customers + +Customer and customer request management. + +| Permission | Owner | Admin | Member | Guest | +| --------------------------- | ----- | ----- | ------ | ----- | +| View Customers | ✓ | ✓ | x | x | +| Create Customers | ✓ | ✓ | x | x | +| Edit Customers | ✓ | ✓ | x | x | +| Delete Customers | ✓ | ✓ | x | x | +| Add Customer Attachments | ✓ | ✓ | x | x | +| Delete Customer Attachments | ✓ | ✓ | x | x | + +### Work Item Relations + +Managing custom relation type definitions for work items. + +| Permission | Owner | Admin | Member | Guest | +| --------------------------- | ----- | ----- | ------ | ----- | +| View Relation Definitions | ✓ | ✓ | ✓ | ✓ | +| Create Relation Definitions | ✓ | ✓ | x | x | +| Edit Relation Definitions | ✓ | ✓ | x | x | +| Delete Relation Definitions | ✓ | ✓ | x | x | + +### Templates + +Creating and managing workspace-level work item, page, and project templates. + +| Permission | Owner | Admin | Member | Guest | +| ---------------- | ----- | ----- | ------ | ----- | +| View Templates | ✓ | ✓ | ✓ | x | +| Create Templates | ✓ | ✓ | x | x | +| Edit Templates | ✓ | ✓ | x | x | +| Delete Templates | ✓ | ✓ | x | x | + +### Plane Runner + +Workspace-level automation rules and configurations. + +| Permission | Owner | Admin | Member | Guest | +| ---------------------------- | ----- | ----- | ------ | ----- | +| View Workspace Automations | ✓ | ✓ | ✓ | x | +| Create Workspace Automations | ✓ | ✓ | x | x | +| Edit Workspace Automations | ✓ | ✓ | x | x | +| Delete Workspace Automations | ✓ | ✓ | x | x | + +## Project permissions + +Workspace Owner and workspace Admin have wildcard access to all project resource types and appear as ✓ throughout the project tables. The columns below cover project-level role assignments only. + +### Project Members + +Inviting, editing, and removing project members. + +| Permission | P-Admin | Contributor | Commenter | Guest | +| -------------------- | ------- | ----------- | --------- | ----- | +| View Project Members | ✓ | ✓ | ✓ | ✓ | +| Invite Members | ✓ | x | x | x | +| Edit Member Details | ✓ | x | x | x | +| Change Member Role | ✓ | x | x | x | +| Remove Members | ✓ | x | x | x | + +### Work Items + +The primary issue surface, including comments, attachments, links, relations, and custom properties. + +| Permission | P-Admin | Contributor | Commenter | Guest | +| ---------------------- | ------- | ----------- | --------- | -------- | +| View Issues | ✓ | ✓ | ✓ | +Creator | +| Create Issues | ✓ | ✓ | x | x | +| Edit Issues | ✓ | ✓ | +Creator | +Creator | +| Bulk Edit Issues | ✓ | ✓ | x | x | +| Export Issues | ✓ | ✓ | x | x | +| React to Issues | ✓ | ✓ | ✓ | x | +| Delete Issues | ✓ | +Creator | x | x | +| Add Comments | ✓ | ✓ | ✓ | x | +| Edit Comments | ✓ | +Creator | +Creator | x | +| React to Comments | ✓ | ✓ | ✓ | ✓ | +| Delete Comments | ✓ | +Creator | +Creator | x | +| View Attachments | ✓ | ✓ | ✓ | ✓ | +| Add Attachments | ✓ | ✓ | ✓ | x | +| Delete Attachments | ✓ | +Creator | +Creator | x | +| View Work Item Links | ✓ | ✓ | ✓ | x | +| Add Work Item Links | ✓ | ✓ | x | x | +| Edit Work Item Links | ✓ | ✓ | x | x | +| Delete Work Item Links | ✓ | ✓ | x | x | +| View Custom Properties | ✓ | ✓ | ✓ | x | +| Edit Custom Properties | ✓ | ✓ | x | x | + +Project Guest sees only their own work items (issues created via intake). All other Guest views of issues are filtered to creator. + +### Epics + +Epic lifecycle, including links, properties, and update threads. + +| Permission | P-Admin | Contributor | Commenter | Guest | +| --------------------------- | ------- | ----------- | --------- | ----- | +| View Epics | ✓ | ✓ | ✓ | x | +| Create Epics | ✓ | ✓ | x | x | +| Edit Epics | ✓ | ✓ | x | x | +| Delete Epics | ✓ | +Creator | x | x | +| View Epic Properties | ✓ | ✓ | ✓ | x | +| Edit Epic Properties | ✓ | ✓ | x | x | +| View Epic Updates | ✓ | ✓ | ✓ | x | +| Post Epic Updates | ✓ | ✓ | x | x | +| Edit Epic Updates | ✓ | +Creator | x | x | +| Delete Epic Updates | ✓ | +Creator | x | x | +| Edit Epic Update Comments | ✓ | +Creator | x | x | +| Delete Epic Update Comments | ✓ | +Creator | x | x | + +### Modules and Cycles + +Feature grouping and sprint/cycle management. + +| Permission | P-Admin | Contributor | Commenter | Guest | +| --------------------- | ------- | ----------- | --------- | ----- | +| View Modules | ✓ | ✓ | ✓ | x | +| Create Modules | ✓ | ✓ | x | x | +| Edit Modules | ✓ | ✓ | x | x | +| Manage Module Members | ✓ | ✓ | x | x | +| Archive Modules | ✓ | ✓ | x | x | +| Export Modules | ✓ | ✓ | x | x | +| Delete Modules | ✓ | +Creator | x | x | +| View Cycles | ✓ | ✓ | ✓ | x | +| Create Cycles | ✓ | ✓ | x | x | +| Edit Cycles | ✓ | ✓ | x | x | +| Delete Cycles | ✓ | +Creator | x | x | + +### Pages and Views + +Project-level pages and saved views. + +| Permission | P-Admin | Contributor | Commenter | Guest | +| --------------------- | ------- | ----------- | --------- | ----- | +| View Pages | ✓ | ✓ | ✓ | ✓ | +| Create Pages | ✓ | ✓ | x | x | +| Edit Pages | ✓ | ✓ | x | x | +| Share Pages | ✓ | ✓ | x | x | +| Delete Pages | ✓ | x | x | x | +| View Project Views | ✓ | ✓ | ✓ | ✓ | +| Create Project Views | ✓ | ✓ | x | x | +| Edit Project Views | ✓ | +Creator | x | x | +| Share Project Views | ✓ | +Creator | x | x | +| Publish Project Views | ✓ | +Creator | x | x | +| Export Project Views | ✓ | ✓ | x | x | +| Delete Project Views | ✓ | +Creator | x | x | + +Page deletion is restricted to project Admins only. Contributors can edit pages but cannot delete them. + +### Intake + +Issue intake and triage workflow. + +| Permission | P-Admin | Contributor | Commenter | Guest | +| ------------------------------------------ | ------- | ----------- | --------- | -------- | +| View Intake | ✓ | ✓ | ✓ | x | +| Create Intake Items | ✓ | ✓ | ✓ | ✓ | +| Submit Intake Requests | ✓ | ✓ | ✓ | ✓ | +| Edit Intake Items | ✓ | +Creator | +Creator | +Creator | +| React to Intake Items | ✓ | ✓ | ✓ | x | +| Manage Intake Items (accept/reject/snooze) | ✓ | x | x | x | +| Configure Intake | ✓ | x | x | x | +| Export Intake | ✓ | ✓ | x | x | +| Delete Intake Items | ✓ | +Creator | +Creator | +Creator | + +Status changes (accept, reject, snooze, mark duplicate) are admin-only. Editing is restricted to creators for non-admin roles, with editable fields limited to name, description, priority, target/start dates, labels, and assignees. + +### Project Configuration + +Labels, states, estimates, and milestones. + +| Permission | P-Admin | Contributor | Commenter | Guest | +| ----------------- | ------- | ----------- | --------- | ----- | +| View Labels | ✓ | ✓ | ✓ | ✓ | +| Create Labels | ✓ | x | x | x | +| Edit Labels | ✓ | x | x | x | +| Delete Labels | ✓ | x | x | x | +| View States | ✓ | ✓ | ✓ | ✓ | +| Create States | ✓ | x | x | x | +| Edit States | ✓ | x | x | x | +| Delete States | ✓ | x | x | x | +| View Estimates | ✓ | ✓ | ✓ | ✓ | +| Create Estimates | ✓ | x | x | x | +| Edit Estimates | ✓ | x | x | x | +| Delete Estimates | ✓ | x | x | x | +| View Milestones | ✓ | ✓ | ✓ | x | +| Create Milestones | ✓ | ✓ | x | x | +| Edit Milestones | ✓ | ✓ | x | x | +| Delete Milestones | ✓ | ✓ | x | x | + +### Automation and Workflows + +Automations, workflow rules, and recurring work items. + +| Permission | P-Admin | Contributor | Commenter | Guest | +| ---------------------- | ------- | ----------- | --------- | ----- | +| View Automations | ✓ | ✓ | x | x | +| Create Automations | ✓ | x | x | x | +| Edit Automations | ✓ | x | x | x | +| Delete Automations | ✓ | x | x | x | +| View Workflows | ✓ | ✓ | ✓ | ✓ | +| Create Workflows | ✓ | x | x | x | +| Edit Workflows | ✓ | x | x | x | +| Delete Workflows | ✓ | x | x | x | +| View Recurring Items | ✓ | ✓ | x | x | +| Create Recurring Items | ✓ | ✓ | x | x | +| Edit Recurring Items | ✓ | ✓ | x | x | +| Delete Recurring Items | ✓ | ✓ | x | x | + +### Project Updates + +Progress updates and comments on updates. + +| Permission | P-Admin | Contributor | Commenter | Guest | +| ------------------------------ | ------- | ----------- | --------- | ----- | +| View Project Updates | ✓ | ✓ | ✓ | ✓ | +| Post Project Updates | ✓ | ✓ | x | x | +| Edit Project Updates | ✓ | +Creator | x | x | +| Delete Project Updates | ✓ | +Creator | x | x | +| Edit Project Update Comments | ✓ | +Creator | x | x | +| Delete Project Update Comments | ✓ | +Creator | x | x | + +### Analytics and Activity + +Project analytics and activity logs. + +| Permission | P-Admin | Contributor | Commenter | Guest | +| ----------------- | ------- | ----------- | --------- | ----- | +| View Activity Log | ✓ | ✓ | ✓ | x | + +### Project Links + +Project-level links. + +| Permission | P-Admin | Contributor | Commenter | Guest | +| -------------------- | ------- | ----------- | --------- | ----- | +| View Project Links | ✓ | ✓ | ✓ | x | +| Add Project Links | ✓ | ✓ | x | x | +| Edit Project Links | ✓ | ✓ | x | x | +| Delete Project Links | ✓ | ✓ | x | x | + +### Templates + +Project-scoped work item and page templates. + +| Permission | P-Admin | Contributor | Commenter | Guest | +| ---------------- | ------- | ----------- | --------- | ----- | +| View Templates | ✓ | ✓ | x | x | +| Create Templates | ✓ | x | x | x | +| Edit Templates | ✓ | x | x | x | +| Delete Templates | ✓ | x | x | x | + +## Teamspace permissions + +Teamspace content access requires teamspace membership. Workspace Owner has full bypass via wildcard. Workspace Admin has resource-level wildcards for teamspace content (view, create, edit, delete teamspace content) but does **not** automatically have teamspace edit, delete, or member management. Those require the teamspace lead condition. + +### Teamspace + +| Permission | TS-Member | TS-Member +Lead | +| -------------- | --------- | --------------- | +| View | ✓ | ✓ | +| Edit settings | x | ✓ +Lead | +| Delete | x | ✓ +Lead | +| Manage members | x | ✓ +Lead | + +### Teamspace Comments + +| Permission | TS-Member | TS-Member +Lead | +| ---------------- | ------------- | --------------- | +| View | ✓ | ✓ | +| Create | ✓ | ✓ | +| Edit (own) | +Creator | ✓ (any) | +| Delete (own/any) | +Creator only | ✓ (any) | +| React | ✓ | ✓ | + +### Teamspace Views + +| Permission | TS-Member | TS-Member +Lead | +| ---------- | ------------- | --------------- | +| View | ✓ | ✓ | +| Create | ✓ | ✓ | +| Edit | +Creator only | ✓ (any) | +| Delete | +Creator only | ✓ (any) | + +### Teamspace Pages + +| Permission | TS-Member | TS-Member +Lead | +| ----------------- | ----------------- | --------------- | +| View | ✓ | ✓ | +| Create | ✓ | ✓ | +| Edit | ✓ (collaborative) | ✓ | +| Delete | Owner only | ✓ (any) | +| Archive/Unarchive | Owner only | ✓ (any) | +| Lock/Unlock | Owner only | ✓ (any) | + +### Teamspace Page Comments + +| Permission | TS-Member | TS-Member +Lead | +| ----------------- | ------------- | --------------- | +| Create | ✓ | ✓ | +| Edit | +Creator only | ✓ (any) | +| Delete | +Creator only | ✓ (any) | +| React | ✓ | ✓ | +| Resolve/Unresolve | ✓ | ✓ | + +## Edge cases and behavioral nuances + +### Workspace Owners and Admins can't be locked out of projects + +Removing a workspace Owner or Admin from a project removes the project-level membership record but has no functional effect. Their workspace-level wildcards still grant access through inheritance. + +### Hidden permissions reserved for specific roles + +| Permission | Holder | Notes | +| ------------------------------- | ------------- | --------------------------------------- | +| Delete Workspace | Owner only | Cannot be granted via custom roles | +| Transfer Ownership | Owner only | Cannot be granted via custom roles | +| Manage Billing | Owner + Admin | Billing access | +| Manage Integrations (uninstall) | Admin only | Some destructive integration operations | + +### Creator-only business rules + +Some restrictions apply regardless of role level. Even an Admin cannot bypass them: + +- A workspace view can only be edited by its creator. +- A project view can only be edited by its creator. + +### Permissions that cannot be added to custom roles + +| Permission | Why | +| ------------------ | ------------------ | +| Full access (`*`) | Reserved for Owner | +| Delete Workspace | Reserved for Owner | +| Transfer Ownership | Reserved for Owner | + +### Permission dependencies + +Some permissions require others to function. The role builder enforces these automatically. Enabling a permission auto-enables its prerequisites, and disabling a prerequisite auto-disables permissions that depend on it. + +Common dependencies: + +- Edit requires View on the same resource type. +- Delete requires View on the same resource type. +- Member management actions require View Members on the relevant scope. + +## Permission gates + +Some permissions only become available when the corresponding feature is enabled at the workspace or project level. If a feature is disabled, the related permissions exist in the role definition but have no effect. + +## Conditional grants summary + +For convenience, here are all the conditional grants in the system: + +| Role | Permission | Condition | +| ------------------- | ------------------------------------------------ | --------- | +| Project Contributor | Delete work items, epics, modules, cycles | Creator | +| Project Contributor | Edit and delete comments and attachments | Creator | +| Project Contributor | Edit, delete, share, and publish views | Creator | +| Project Contributor | Edit and delete intake items | Creator | +| Project Contributor | Edit and delete project, epic, and cycle updates | Creator | +| Project Contributor | Edit and delete project assets | Creator | +| Project Commenter | Edit and delete intake work items | Creator | +| Project Commenter | Edit and delete comments | Creator | +| Project Guest | View, edit, and delete intake items | Creator | +| Workspace Member | Edit and delete workspace views | Creator | +| Workspace Member | Edit and delete wiki collections | Creator | +| Workspace Member | Edit and delete initiative comments | Creator | +| Workspace Member | Delete initiative attachments | Creator | +| Workspace Member | Delete workspace drafts | Creator | +| Teamspace Member | Edit, delete, and manage teamspace | Lead | +| Teamspace Member | Edit and delete teamspace comments | Creator | +| Teamspace Member | Edit and delete teamspace views | Creator | + +## See also + +- [Roles and permissions](/roles-and-permissions/overview) +- [Member roles](/roles-and-permissions/member-roles) +- [Manage workspace members](/core-concepts/workspaces/members) +- [Manage project members](/core-concepts/projects/manage-project-members) +- [Create custom roles](/roles-and-permissions/custom-roles) diff --git a/docs/workspaces-and-users/permissions.md b/docs/workspaces-and-users/permissions.md deleted file mode 100644 index da5d7cb8..00000000 --- a/docs/workspaces-and-users/permissions.md +++ /dev/null @@ -1,1992 +0,0 @@ ---- -title: Permissions matrix -description: Manage user roles and permissions in workspaces. ---- - -# Permissions matrix - -Permissions define what actions users can take within a workspace or project. - -This reference provides a comprehensive breakdown of what each role can do across workspaces and projects. Use this matrix to understand exact permission boundaries when planning your team structure or troubleshooting access issues. - -## Permission levels - -::: details Workspaces - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
PermissionAdminMemberGuest
Access Workspace settings✓xx
Create Workspace✓xx
Update Workspace✓xx
Delete Workspace✓xx
Add user✓xx
Remove user✓xx
Change user role✓xx
Manage Project states✓xx
Manage Billing and plans✓xx
Manage Integrations✓xx
Manage Imports✓xx
Manage Exports✓xx
Manage Webhooks✓xx
Manage API tokens✓xx
Manage Worklogs✓xx
Home✓✓✓
Your work✓✓x
Inbox✓✓✓
Drafts✓✓x
Projects✓✓x
View private projects✓xx
View public projects✓✓x
Join private projects✓xx
Join public projects✓✓x
Cycles✓✓x
Views✓✓✓
Analytics✓✓x
Your favourites✓✓x
- -::: - -::: details Projects - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
PermissionWorkspace AdminProject AdminMemberGuest
Access Project settings - ✓ - - ✓ - - x - - x -
Create Project - ✓ - - ✓ - - ✓ - - x -
Update Project - ✓ - - ✓ - - x - - x -
Archive Project - ✓ - - ✓ - - x - - x -
Delete Project - ✓ - - ✓ - - x - - x -
Add user - ✓ - - ✓ - - x - - x -
Remove user - ✓ - - ✓ - - x - - x -
Change user role - ✓ - - ✓ - - x - - x -
Enable features - ✓ - - ✓ - - x - - x -
Manage work item states - ✓ - - ✓ - - x - - x -
Manage work item labels - ✓ - - ✓ - - x - - x -
Manage Estimates - ✓ - - ✓ - - x - - x -
Manage Automations - ✓ - - ✓ - - x - - x -
Manage work item types and custom properties - ✓ - - ✓ - - x - - x -
Add Project to favorites - ✓ - - ✓ - - ✓ - - x -
Publish Project - ✓ - - ✓ - - x - - x -
Copy link - ✓ - - ✓ - - ✓ - - x -
View Archived projects - ✓ - - ✓ - - ✓ - - x -
-::: - -::: details Work items - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
PermissionWorkspace AdminProject AdminMemberGuest - Guest with
view access - 		Comments
Create Work item - ✓ - - ✓ - - ✓ - - x - - x -
View Work items - ✓ - - ✓ - - ✓ - - x - - ✓ - Guests without view access can only see their own work items accepted through Intake.
Edit Work item - ✓ - - ✓ - - ✓ - - x - - x -
Duplicate Work item - ✓ - - ✓ - - ✓ - - x - - x -
Copy link - ✓ - - ✓ - - ✓ - - x - - x -
Archive Work item - ✓ - - ✓ - - ✓ - - x - - x -
Delete Work item - ✓ - - ✓ - - ✓ - - x - - x -
Edit Work item properties - ✓ - - ✓ - - ✓ - - x - - x -
View Work item activity - ✓ - - ✓ - - ✓ - - x - - ✓ -
Log work - ✓ - - ✓ - - ✓ - - x - - x -
Add Comments - ✓ - - ✓ - - ✓ - - x - - ✓ -
View Comments - ✓ - - ✓ - - ✓ - - x - - ✓ -
Add Reactions - ✓ - - ✓ - - ✓ - - x - - ✓ -
View work item types - ✓ - - ✓ - - ✓ - - ✓ - - ✓ -
Use work item types - ✓ - - ✓ - - ✓ - - x - - x -
-::: - -::: details Cycles - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
PermissionWorkspace AdminProject AdminMemberGuest
Create Cycle - ✓ - - ✓ - - ✓ - - x -
View Cycles - ✓ - - ✓ - - ✓ - - x -
View Cycle work items - ✓ - - ✓ - - ✓ - - x -
Edit Cycle - ✓ - - ✓ - - ✓ - - x -
Add work items - ✓ - - ✓ - - ✓ - - x -
Archive Cycle - ✓ - - ✓ - - ✓ - - x -
Delete Cycle - ✓ - - ✓ - - ✓ - - x -
Copy link - ✓ - - ✓ - - ✓ - - x -
Add Cycle to favorites - ✓ - - ✓ - - ✓ - - x -
View Cycle details - ✓ - - ✓ - - ✓ - - x -
Filter Cycles - ✓ - - ✓ - - ✓ - - x -
Search Cycles - ✓ - - ✓ - - ✓ - - x -
-::: - -::: details Modules - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
PermissionWorkspace AdminProject AdminMemberGuest
Create Module - ✓ - - ✓ - - ✓ - - x -
View Modules - ✓ - - ✓ - - ✓ - - x -
View Module work items - ✓ - - ✓ - - ✓ - - x -
Edit Module - ✓ - - ✓ - - ✓ - - x -
Add work items - ✓ - - ✓ - - ✓ - - x -
Archive Module - ✓ - - ✓ - - ✓ - - x -
Delete Module - ✓ - - ✓ - - ✓ - - x -
Copy link - ✓ - - ✓ - - ✓ - - x -
Add Module to favorites - ✓ - - ✓ - - ✓ - - x -
View Module details - ✓ - - ✓ - - ✓ - - x -
Add links to Module - ✓ - - ✓ - - ✓ - - x -
Sort Modules - ✓ - - ✓ - - ✓ - - x -
Filter Modules - ✓ - - ✓ - - ✓ - - x -
Search Modules - ✓ - - ✓ - - ✓ - - x -
-::: - -::: details Views - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
PermissionWorkspace AdminProject AdminMemberGuest - Guest with
view access - 		Comments
Create View - ✓ - - ✓ - - ✓ - - ✓ - - ✓ -
See Views - ✓ - - ✓ - - ✓ - - x - - ✓ - Guests without view access can only see the Views they create
Edit View - ✓ - - ✓ - - ✓ - - x - - ✓ -
Add work items - ✓ - - ✓ - - ✓ - - x - - x -
Delete View - ✓ - - ✓ - - ✓ - - x - - ✓ -
Sort Views - ✓ - - ✓ - - ✓ - - x - - ✓ -
Filter Views - ✓ - - ✓ - - ✓ - - x - - ✓ -
Search Views - ✓ - - ✓ - - ✓ - - x - - ✓ -
Add View to favorites - ✓ - - ✓ - - ✓ - - x - - x -
Publish View - ✓ - - ✓ - - ✓ - - x - - x -
Copy link - ✓ - - ✓ - - ✓ - - x - - x -
-::: - -::: details Pages - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
PermissionWorkspace AdminProject AdminMemberGuest - Guest with
view access -
Create Page - ✓ - - ✓ - - ✓ - - x - - x -
View Pages - ✓ - - ✓ - - ✓ - - x - - ✓ -
Edit Page - ✓ - - ✓ - - ✓ - - x - - x -
Archive Page - ✓ - - ✓ - - ✓ - - x - - x -
Delete Page - ✓ - - ✓ - - ✓ - - x - - x -
Add Page to favorites - ✓ - - ✓ - - ✓ - - x - - x -
Publish Page - ✓ - - ✓ - - ✓ - - x - - x -
Copy link - ✓ - - ✓ - - ✓ - - x - - x -
Sort Pages - ✓ - - ✓ - - ✓ - - x - - ✓ -
Filter Pages - ✓ - - ✓ - - ✓ - - x - - ✓ -
Search Pages - ✓ - - ✓ - - ✓ - - x - - ✓ -
-::: - -::: details Intake - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
PermissionWorkspace AdminProject AdminMemberGuest - Guest with
view access - 		Comments
Create Intake work item - ✓ - - ✓ - - ✓ - - ✓ - - ✓ -
View Intake work items - ✓ - - ✓ - - ✓ - - ✓ - - ✓ - Guest without view access can only view the Intake work items they create
Edit Intake work item - ✓ - - ✓ - - x - - ✓ - - x - Guest without view access can only modify the Intake work items they create
Accept Intake work item - ✓ - - ✓ - - x - - x - - x -
Reject Intake work item - ✓ - - ✓ - - x - - x - - x -
Snooze Intake work item - ✓ - - ✓ - - ✓ - - x - - x - Members can't snooze work items created by other users
Mark duplicate - ✓ - - ✓ - - ✓ - - x - - x - Members can't mark duplicate Intake work items created by other users
Delete Intake work item - ✓ - - ✓ - - ✓ - - x - - x - Members can't delete Intake work items created by other users
Add attachments - ✓ - - ✓ - - ✓ - - ✓ - - ✓ - Members and Guests can only attach files to the Intake work items they create
Modify Intake work item properties - ✓ - - ✓ - - ✓ - - ✓ - - ✓ - Members and Guests can only modify Intake work item properties they create
View activity - ✓ - - ✓ - - ✓ - - x - - ✓ -
Add comments - ✓ - - ✓ - - ✓ - - x - - ✓ -
Add reactions - ✓ - - ✓ - - ✓ - - x - - ✓ -
Copy link - ✓ - - ✓ - - ✓ - - x - - ✓ -
Sort Intake work items - ✓ - - ✓ - - ✓ - - ✓ - - ✓ -
Filter Intake work items - ✓ - - ✓ - - ✓ - - ✓ - - ✓ -
-::: - -## See also - -- [Member roles](/workspaces-and-users/roles) -- [Manage members](/core-concepts/workspaces/members) diff --git a/docs/workspaces-and-users/roles.md b/docs/workspaces-and-users/roles.md deleted file mode 100644 index 9ea2ec17..00000000 --- a/docs/workspaces-and-users/roles.md +++ /dev/null @@ -1,52 +0,0 @@ ---- -title: Member roles -description: Learn about workspace roles in Plane - Admin, Member, and Guest permissions. Reference guide covering role capabilities, limitations, and when to use each role type for your team. ---- - -# Member roles - -Every user in your workspace has a role that determines their access level and permissions. Plane uses three role types - Admin, Member, and Guest - each designed for different levels of involvement and responsibility. - -## Types of roles - -### Admin - -**Workspace governance** -Admins control the workspace itself - settings, members, features, and access. They determine what capabilities are available to all Members. It provide complete control for workspace owners and senior stakeholders who need to manage team structure and configuration. This centralized authority prevents configuration conflicts and maintains consistent workspace policies. - -### Member - -**Contributor autonomy** -Members can do their work - create projects, manage work items, collaborate with the team - without needing administrative overhead. They see the full workspace membership (fostering transparency) and can discover public projects (encouraging collaboration), but cannot alter workspace structure or invite others. This separation keeps Members focused on execution rather than governance. - -### Guest - -**Controlled external access** -Organizations frequently need to give clients, contractors, or stakeholders visibility into work without exposing the entire workspace or allowing them to be assigned tasks. Guests exist outside the workspace's core structure. They cannot see workspace members, settings, or the broader project landscape. Their access is project-specific and tightly scoped, ensuring external collaborators only interact with content relevant to them. - -## When to use each role - -**Choose Admin for:** - -- Workspace owners -- Technical leads responsible for workspace governance -- People who need to manage team membership and workspace settings -- Anyone responsible for enabling features, configuring integrations, or managing billing - -**Choose Member for:** - -- Full-time team members who actively contribute to projects -- Internal collaborators who should have visibility into the workspace team -- Anyone who needs to create projects or access workspace features - -**Choose Guest for:** - -- External clients who need to review specific project deliverables -- Contractors contributing to particular work items via the Intake section -- Stakeholders who need visibility into specific projects without editing permissions -- Anyone who should remain isolated from the broader workspace structure and membership - -## See also - -- [Permissions matrix](/workspaces-and-users/permissions) - Complete breakdown of what each role can do -- [Manage members](/core-concepts/workspaces/members) - Invite users, change roles, and remove members diff --git a/vercel.json b/vercel.json index 281b5b4a..290d0eba 100644 --- a/vercel.json +++ b/vercel.json @@ -261,6 +261,14 @@ { "source": "/performance/hyper-mode", "destination": "/" + }, + { + "source": "/workspaces-and-users/permissions", + "destination": "/roles-and-permissions/permissions-matrix" + }, + { + "source": "/workspaces-and-users/roles", + "destination": "/roles-and-permissions/member-roles" } ] }