Skip to main content
System StatusContact Support

Documentation related to the following products will soon be moved to a new portal: ( Agility, Agility Connect and Agility Integrations Continuum and ALM Connect
Links from the site will automatically redirect to the new site.
If you have any questions, please contact Support. Agility Community

Assigning a Project Role

This feature is available in all editions.



A member's Project Role grants them access to projects based on the role they play (Example: team member, project lead, tester, and so on) and determines if they can create, view, and modify project assets. This article is intended for project and member administrators responsible for assigning and managing projects membership and project role assignments.

About Project Roles

Here are a few important things to know:

  • A member's Project Role is different than their Admin Privileges role. See Roles & Project Membership for details.

  • A member may have different roles on different projects.

  • Project role assignments automatically apply to all child projects (unless explicitly changed).

  • Project role assignments made in a child project do not affect the parent or any other child projects.

  • At any level in the project tree hierarchy, a member's project role can be changed to increase or decrease project permissions.

  • You must have administrator or lead-level permissions to assign project roles to other members.

Before a project role can be assigned, the member must first be assigned to the project. This grants the member access to the project so they can see it in their Project Navigator and Project Tree. See Assigning a Member to Project for instructions.

Option 1. Assigning a Project Role on the Member Roles Page

  1. From the sidebar, click Admin Admin.png > Projects Member Roles

  2. Expand the project tree, select a project, and then click Manage next to the project name. 

  3. For each member, select a role from the New Project Role/Owner List drop-down list and then select the checkbox if you want the member's name to display in the Owners list.

  4. Click Save.


Option 2. Assigning a Project Role on the Project Roles Page

  1. From the sidebar, click Admin Admin.png > Members Project Roles.

  2. Click Manage next to a member's name. 

  3. Expand the project tree, and then select the roles from the New Project Role/Owner List drop-down list.

  4. Click Save.

Option 3. Updating a Project Role on the Member's Details Page

  1. From the Admin menu, select Members , and then click on the member's name.
  2. Click on the "Project Membership" link, at the top, just below the blue/green colored top header bar to take you to the "Project Membership" grid.
  3. Click the wrench button to customize the grid, to include the "New Project Role/.." column.(Note: Select both the "Display" and "Edit" check boxes for this column).
  4. Click through the project list, and locate the project of which the role is being updated for.
  5. Click the drop-down button under the "New Project Role" column and select the new role.
  6. Click the "Save" button.

Project Roles Summary

These project roles work well for most organizations:

  • For most members, the Team Member role is sufficient. This is a great "go to" role that grants the user basic access to any project and will allow them to begin working immediately. 

  • Assign the Project Lead role to members who need to manage the schedule (e.g., Product or Project Manager).

  • Assign the Observer role to members who want to view progress (e.g., Executive Management).

Role Name
View Edit
Project Specific Access
(System, Member, Project)
Project Lead
Team Member
No Access
Backlog Groups
Backlog Items
Portfolio Items
Regression Tests
Sprint/Iteration Schedules



Recommended Uses...

System Administrator

This role is not the traditional super user role you typically think of  (e.g., Root for Unix, or Administrator for Windows). While they can make some system configuration changes, their access to projects can be restricted by their project and project role assignments.

For the project(s) to which they are assigned, they have full read/write access and can add and remove members, change member roles, and manage sprints and schedules.

This role is intended for individuals who are responsible for managing system configuration settings and managing members and projects.

Member Admin

Full read/write access to the project(s) to which they are assigned, including the ability perform member administration tasks and change member roles. They cannot make system configuration changes, but can manage schedules.

This role is intended for use in organizations where member administration can be delegated.

Project Admin 

Full read/write access to the project(s) to which they are assigned. They can create and edit all project assets (backlog items, including defects, tasks, tests, etc.). They can also add/remove project members and change project roles. They cannot, however, perform any system configuration or member administration tasks.

This role is intended for use in organizations where project-level administration can be delegated.

Project Lead

Project Leads have similar project-level rights as Team Member, but they can also create/edit Project details to which they are assigned, Goals, Roadmaps, Rooms, and Strategic Themes.


Team Member

(Recommended for most users) Team Members can view, edit, and create all project artifacts, including adding and removing items from sprints. Finally, they can view, but not modify or create the project schedule.

It is recommended that you use this role as the default for all members and assign other roles only as needed.


Developers can view all project artifacts, but can only create and edit tasks, defects, issues and requests. Furthermore, they can only log effort against a task.

Use this role only if you need to restrict a team member's access to development artifacts, otherwise you can use the Team Member role for a developer.


Members with this role can view all project artifacts, but can only create and edit test, defects, issues, and requests. Furthermore, they can only log effort against tests. Tester role can also work in Regression Planning and create Test Plans and Suites and generate Test Sets.

Use this role only if you need to restrict a team member's access to test artifacts, otherwise you can use the Team Member role for a tester.


Customers can view all project artifacts, but can only create and edit stories, defects, test sets, feature groups, goals, request, issues, and tests.

Use this role to restrict a member's access to business-related artifacts (e.g., the Product Owner in Scrum).


Requestors can view all project artifacts, but can only create and edit requests.

Choose this role to grant access to managing input into project, but not the project work itself.


Observers have read-only access to all project artifacts.

This role is valuable for anyone (such as executives) who needs to track, but not edit a project.


Visitors can view backlog items but they cannot see any of the details (e.g., tasks, tests, etc.) below the items.

This role is useful for anyone who needs an overview of a project, but does not need to see detailed tracking information.


Inheritors can see a project in the project tree, but cannot access project contents.

Use this role on higher-level projects if you have read/write access to multiple low-level projects and need to coordinate plans or roll-up reporting. Members do not have access to information on the higher-level projects.

No Access

This role denies access to a given project.

This role is good if you want to grant access to higher-level projects, but you do not want the member to know that a lower-level projects exist