Custom Roles

Last updated: September 23, 2026

Background

Default roles — Viewer, Member, Admin — are one-size-fits-all, which often means granting someone more access than they need just to let them do their job. Custom Roles lets your organization's admins build their own permission templates that match how your team actually works: a "Field Supervisor" with limited edit rights, a "Legal Reviewer" with read-only document access, or a "Project Owner" with full control over a single project. Roles can be created from scratch or copied from an existing template, and assigned at the org, team, or project level. This replaces informal workarounds like making everyone an Admin, and keeps sensitive work — legal reviews, executive reports, compliance documents — behind roles only the right people hold.

Things to Consider

  • Only org admins can create, edit, or delete custom roles. Team admins cannot manage roles for their own team without full org admin access.

  • Access is additive only — there is no way to subtract or deny access. A role assigned at a lower scope can only add to what a user already has. If a user's team role already exceeds a project-level option, that option is disabled in the project role picker.

  • A user can have a higher role on a specific project than at the team level. This is supported and common. Because it isn't always clear whether a custom role is higher or lower than a parent role, the project role will always display as being in addition to the team role (for example, "+ Editor (team role)").

  • Custom roles are opt-in. If your org doesn't create any, nothing changes — existing accounts keep their current behavior.

  • Permissions for Workflows, Skills, Redlining, and Agent Memory are not yet covered by custom roles. Currently gate-able areas include Manage Users, org/team/project actions (labels, reviews and playbooks, comments), folders, tasks, document actions (create, read, update, delete, comment, markup, download, apply reviews and playbooks), and chat.

  • Folder- and file-level access gating is not yet available. Today, access is controlled at the org, team, and project level only.

  • Removing a user from a role is permanent. There is no way to temporarily suspend access — the only option today is a hard Remove.

Steps

Create a custom role from scratch

  1. Go to Organization Settings → User Roles.

  2. Click New in the Custom header.

  3. Give the role a name and a description.

  4. Select the permissions you want the role to include.

  5. Click Create role. The role is now available to assign anywhere in your org.

Create a custom role from an existing template

  1. Go to Organization Settings → User Roles.

  2. Find the default role closest to what you need and click Copy & edit.

  3. Name the role, then toggle individual permissions on or off.

  4. Click Create role. The role is now available to assign anywhere in your org.

Tip: Copying and editing an existing template is usually faster than starting from scratch, and it's the recommended way to handle one-off exceptions — rather than trying to adjust a single user's access directly.

Assign a custom role to a user

  1. Navigate to the scope where you want to assign the role:

    • Org level: the Org Members page

    • Team level: a team's Members tab

    • Project level: a project's Members panel

  2. Find the user and open their role picker, either in the user table or the permission drawer.

  3. Select the custom role from the list. If the custom role differs from the role the user holds at the parent level, subtext will appear showing that both roles apply — for example, "+ Editor (team role)."

  4. Confirm. The assignment takes effect immediately.

Note: A custom role applies at the scope you assign it. For example, a role that includes "Manage User Permissions" assigned at the project level lets that user manage users on that project only — not across the whole team or org.

Delete a custom role

  1. Go to Organization Settings → User Roles.

  2. Open the … menu at the end of the role and click Delete custom role.

  3. Review the impact preview, which shows how many users hold the role and at which scopes.

  4. Reassign the affected users to another role. Deletion is blocked until every assignment is resolved.

Note: No one's access changes silently when a role is deleted. Reassignment is always an explicit step.

Common Use Cases

A legal reviewer who should see everything but change nothing. Create a "Legal Read-Only" role with document read and comment rights only, then assign it at the org level. The reviewer can see every contract across all teams but cannot create projects, move documents, or manage users.

A project manager with full control over their own projects only. Assign the Admin role — or a custom "Project Owner" role — at the project level for the specific projects they run. They get full control there, and nothing else on the team is affected.

Limiting who can manage users. Create a role identical to the Member template but with "Manage Users" removed, then reassign affected users to it. User management stays with admins and designated leads.