set-permissions-access-work-tracking.md

title	titleSuffix	description	ms.technology	ms.prod	ms.assetid	ms.manager	ms.author	author	ms.topic	monikerRange	ms.date
Set work tracking permissions	VSTS & TFS	How to grant or restrict access to work tracking tasks for Visual Studio Team Services & Team Foundation Server	devops-security	devops	5AD0BF62-C91E-46DD-8C1A-C8D1F8F8D05F	douge	kaelli	KathrynEE	conceptual	>= tfs-2013	11/27/2017

Set permissions and access for work tracking

[!INCLUDE temp]

You grant or restrict access to various work tracking features by granting users or groups specific permissions for an object, team project, or collection. Or, when you assign a user as a team administrator, they have permissions to manage all assets for the specific team. Add users to the Contributors group to provide access to most features as listed in Permissions and access for work tracking.

[!div class="mx-tdBreakAll"]

Role or permission level	Functional areas set
Team administrator role	- Configure team settings - Define and edit team dashboards - Define and edit team-level work item templates - Add team members and team administrators
Object-level permissions	- Modify work items under an area path - Create and edit nodes under an area path or iteration path - Define and edit queries or query folders - Define and edit Delivery Plans
Project-level permissions	- Create work item tags - Delete and restore work items - Move work items out of a team project - Permanently delete work items - Delete test artifacts - Edit shared work item queries - Add teams and team administrators - Create and manage area and iteration paths - Edit project-level permissions - Customize a team project (On-premises XML or Hosted process models)
Project collection-level permissions	- Create, delete, or edit a process (Inheritance process model, VSTS only) - Edit collection level permissions

Project collection-level permissions include all permissions you can set at the project-level.

To add a user to the team administrator role, see Add a team administrator.

Edit project-level or collection-level/instance-level information

The Edit project-level information and Edit instance-level information (also referred to as Edit collection-level information) provide permissions to several work tracking features as summarized below. To add users or set permissions at these levels, see Add administrators, set permissions at the project-level or project collection-level.

[!div class="mx-tdBreakAll"]

Edit project-level information	Edit instance-level information

• Add and administer teams and all team-related features
  - Create and modify areas and iterations
  - Edit shared work item queries
  - Edit team project level permission ACLs
  - Manage process templates
  - Customize a team project
  - Create and modify global lists
  - Edit event subscriptions (email or SOAP) on team project level events.|- Add and administer teams and all team-related features
  - Create and modify areas and iterations
  - Edit check-in policies
  - Edit shared work item queries
  - Edit team project level and collection level permission ACLs
  - Manage process templates
  - Customize a team project or process
  - Create and modify global lists
  - Edit event subscriptions (email or SOAP) on team project or collection level events. |

Create child nodes, modify work items under an area path

Permissions you set on an area path allow you to permit or restrict access to edit or modify work items, test cases, or test plans assigned to those areas. You can restrict access to users or groups. You can also set permissions for who can add or modify areas or iterations for the team project.

1. From the web portal admin context, open the Work>Areas page, and then click the context menu for the node you want to manage.

   

2. Select the group or team member, and then change the permission settings. If you don't see the group you want, try adding it first.

   For example, here we've added the Disallow Access Group, and disallowed members of this group the ability to view, modify, or edit work items in the Customer Service area path.

   

You can specify two explicit authorization states for permissions: Deny and Allow. In addition, permissions can exist in one of three additional states. To learn more, see About permissions and groups.

Define and edit queries or query folders

You can specify who can add or edit query folders or queries at the object-level. See Set permissions on a shared query or query folder to restrict who can modify the query or queries within a folder.

To learn more about queries, see Create managed queries to list, update, or chart work items.

::: moniker range=">= tfs-2017"

Manage or edit Delivery Plans

The creator of a Deliver Plan as well as all members of the Project Collection Administrators and Project Administrators groups have permissions to edit, manage, and delete plans. To learn more about Delivery Plans, see Review team delivery plans.

Plans are an object within a team project. You manage plan permissions for each plan similar to the way you manage permissions for shared queries or query folders. ::: moniker-end ::: moniker range="tfs-2017"

Note

Feature availability: Delivery plans are available for TFS 2017.2 and later versions, you can access plans by installing the Delivery Plans Marketplace extension.

::: moniker-end ::: moniker range=">= tfs-2017" 0. To grant permissions to a group or user to manage or edit a specific plan, click the actions icon to open the Security dialog for the plan.

<img src="_img/review-tp-open-security-dialog.png" alt="Open the Permissions dialog for a plan" style="border: 1px solid #C3C3C3;" />    

0. Add a user or group who you want to grant permissions to or restrict access. By default, non-administrators can't delete or edit a plan that you create.

1. With the user or group selected, set the permission you want them to have to Allow.

   For example, here we grant permission to Raisa to edit the plan.

   

::: moniker-end

Move or permanently delete work items

By default, Project Administrators and Contributors can change the work item type and delete work items by moving them to the Recycle bin. Only Project Administrators can permanently delete work items and test artifacts. Project admins can grant permissions to other team members as needed.

For example, as a project admin you can grant a user, team group, or other group you've created to have these permissions. Open the Security page for the team project and choose the user or group you want to grant permissions. (To learn how to access the Project level Security page, see Set permissions at the project-level or project collection-level.)

In this example, we grant members assigned to the team administrator role, who belong to the Team Admin groups, permissions to move work items to another team project and to permanently delete work items.

Delete test artifacts

In addition to the project-level permissions set in the previous section, team members need permissions to manage test artifacts which are set for an area path.

Open the Security page for the area path and choose the user or group you want to grant permissions.

Set the permissions for Manage test plans and Manage test suites to Allow.

To have full access to the Test feature set, your access level must be set to Advanced. Users with Basic access and with permissions to permanently delete work items and manage test artifacts can only delete orphaned test cases.

::: moniker range="vsts"

Customize an inherited process

By default, only Project Collection Administrators can create and edit processes. However, these admins can grant permissions to other team members by explicitly setting the Create process, Delete process, or Edit process permissions at the collection level for a specific user.

To customize a process, you need to grant Edit process permissions to a user account for the specific process.

1. Open the … context menu for the inherited process and choose Security.

   

2. Add the account name of the person you want to grant permissions to, set the permissions to Allow that you want them to have, and then click Save changes.

   Here we add Christie Church and allow her to edit the process.

   

Note

Each process is a securable unit and has individual access control lists (ACLs) that govern creating, editing, and deleting inherited processes. At the collection level, team project collection administrators can choose which processes can be inherited from and by whom. When you create a new inherited process, the process creator as well as team project collection administrators have full control of the process and can also set individual ACLs for other users and groups to edit and delete the process.

::: moniker-end

Additional options for restricting access to work items

Note

You can use one or more of the following options with the Hosted XML or On-premises XML process models. To learn more about process models, see Customize work tracking experience.

You can restrict access to work tracking objects in one of two ways:

• By adding WITs to the Hidden Categories group, you can prevent the majority of project contributors from creating them. You can create a hyperlink to a template that opens the work item form and share that link with those team members who you do want to create them.
• Set a condition field rule, a condition-based field rule or a combination of the two that applies to a group. You can restrict changes from being made to a field by specifying a qualifying rule and making it apply for a specific group. Conditional rules can include CANNOTLOSEVALUE, EMPTY, FROZEN, NOTSAMEAS, READONLY, and REQUIRED elements.

For more information about how to customize WITs, see Modify or add a custom work item type (WIT).

Related notes

• Set permissions on queries and query folders
• Permissions and access for work tracking
• Permissions and groups reference