How to Create a Custom Project Role

A custom project role is a named set of permissions on a workspace, assigned to a member. It answers "what may this person do here?" The map of access layers, organization versus workspace versus a share, is how project access works. This page is the narrower job: create one role and apply it. The example is a reviewer who can comment and must not edit tasks.

You need to be allowed to manage roles in that workspace. Creating a role does not invite the person. Assign the role to someone who is already a member, or invite them with that role.

Build the reviewer

Name the role "Reviewer," not "Limited" or "New." The name should tell the next administrator what they are granting.

For a reviewer who comments on tasks and does not change them, start from the workspace permissions that match that sentence:

• Include Comment on tasks.
• Include View own tasks if they should see work assigned to them.
• Include View all tasks only if they should see every task in the projects they can open, not only their own.
• Leave off Edit tasks, Delete tasks, Assign tasks, Create tasks, and Manage statuses.
• Leave off Manage task relationships unless they must draw Blocks links. A reviewer usually should not.
• Leave off Manage workspace settings, Manage members and invites, Manage roles, Create projects, Manage projects, and Manage sections.
• Leave off Manage item sharing unless this person is allowed to grant access to others. A reviewer should not.

That list is the workspace catalog, in the labels the role editor uses. It is not a generic security diagram. If a box is not in that catalog, do not invent it. In particular, the workspace role editor does not offer organization-wide switches such as creating workspaces for the whole organization or managing organization roles. Those belong on an organization role, and they are the wrong tool for a reviewer.

Do not turn on a permission because it sounds like reporting. There is no project reporting suite to unlock. A flag is not a dashboard, an export, or a scheduled email.

View is not the same as a share

A role lets the member act inside the workspace at that power. A guest or client often should not receive a role that can view all tasks and then wander the workspace. For an outside reviewer, the usual pattern is a limited member plus a share on one project, section, or task, at comment level. That pattern is client access without the whole workspace. Use the custom role when the person is a real workspace member whose job is review across the projects they are allowed to open. Use the share when the boundary is one item.

Comment on tasks in the role and a comment share are easy to confuse. The role applies to what their membership can reach. The share applies to the item you pointed at. If you need both, set both. If you only need one task reviewed, do not create a role for it.

Assign it, then test it

1. Save the role with only the boxes you can explain.
2. Assign it to one person.
3. Ask them to open a task and try to edit the title. They should not be able to.
4. Ask them to comment. They should be able to, if the task is one they can see.
5. Ask them to invite someone. They should not be able to.

If step 3 fails, an edit permission is still on, or they have another membership. If step 4 fails, they cannot see the task: view permission or share is missing. Fix the failed step. Do not add every box until the test passes.

Remove the role from yourself only when another person can still manage roles. A workspace with nobody who can manage roles is an avoidable lockout.

A second example, briefly

A "contributor" who creates and edits tasks, assigns them, and comments, but does not manage members or roles, is the same method with more task boxes and still no workspace-admin boxes. Build it when a real person needs it. Do not prebuild a catalogue of ten roles on an empty workspace. Unused roles get assigned by mistake because the name sounded close enough.

What a role will not do

It will not hide a single project by itself if the person can view all projects. Narrow that with the view permissions and with which projects exist in the workspace. It will not replace HR permissions. It will not bill, automate, or send a report. It will not apply inside a different workspace. Membership is per workspace. The same person can be a reviewer in one workspace and a contributor in another.

Changing the role changes it for everyone who has it. If one reviewer must edit "just this once," do not add Edit tasks to the role. Give that person a different role, or change the share on that item if a share is the right layer.

After the role has been used for a week

Look at what the reviewer actually did. If they never commented and instead sent the notes in chat, the role is fine and the habit is elsewhere. Point them at the task comment. If they were blocked on something they legitimately must do, such as ticking a checklist line assigned to them, confirm that action is covered by comment or by the share you gave, and add a permission only when you can name the blocked action. "They felt limited" is not a name.

If a second reviewer needs the same limits, assign the same role. If the second person must edit one project and only comment on another, one role cannot express that. That difference is a share or a different membership, not a stack of exceptions on Reviewer. Editing the role to please one person changes every reviewer.

Write the role's one-sentence purpose next to the name in whatever note you keep for administrators: "Comment on tasks they can see. Cannot edit or invite." When the sentence no longer matches the boxes, the role has drifted. Uncheck the extra box or rename the role so the next invite is honest.

Leave organization-level powers untouched while you do this. A reviewer who cannot create a workspace is a success, not a missing feature.

Conclusion

Create a custom role by naming it and turning on only the workspace permissions that match the job. A reviewer gets comment access and does not get edit, delete, or member management. Assign it, then test with that person. Keep organization-wide powers and item shares in their own layers. Roles are part of /pms.

One mistake to avoid

Do not tick every remaining box after the test fails once. A reviewer who cannot see a task needs view or a share, not Edit tasks, Delete tasks, and Manage members. Add the missing view. Run the test again. Stop when comment works and edit does not.