Customize your work tracking experience
TFS 2017 | TFS 2015 | TFS 2013
As you plan and track your project, you'll find you may want to configure a feature or customize your experience to meet your team's tracking needs. You configure teams and team Agile tools through the web portal administration context for Azure Boards. The method you use to customize projects, which impacts all teams, depends on the process model you use.
If you're new to Azure Boards and work item tracking, see What is Azure Boards? and Track work with user stories, issues, bugs, features, and epics.
This article provides a high-level overview of the customizations you can make and how they differ for the three process models. For guidance on customizations to make to support business decisions, see Configure and customize Azure Boards.
Customizations you make occur at one of these four levels:
- Project-level shared resources: Define area and iteration paths which teams select to configure their backlogs and boards. Shared queries and work item tags are additional objects that once defined can be shared across the project.
- Team assets or tools: Each team can configure their specific tools, such as backlogs, boards, and dashboards. For details, see About teams and Agile tools.
- Project and object-level permissions: Grant or restrict access to work tracking tools, which includes setting permissions for objects and the project and assigning users or groups to specific access levels.
- Collection-level process customization: Customize the fields, work item types, and backlogs and boards available to all teams.
Project-level shared resources
Each project provides a number of shared resources that support all teams added to the project. You configure these features through the user interface or the admin context of the web portal. To understand how the system uses area and iteration paths, see About area and iteration paths.
| Area path pick lists | Sprint/iteration pick lists |
|---|---|
Change the pick list of area paths to support grouping work items by team, product, or feature area. |
Change the pick list of iteration paths to support grouping work into sprints, milestones, or other event-specific or time-related period. Activate sprints for each team. |
| Shared queries | Tags |
|---|---|
| Open shared queries or create your own query using the query editor to list work items or show hierarchical or dependent items.<br/  |
Add tags to work items to filter backlogs and queries, or list items by tags |
Identity fields, people-picker fields
The Assigned To and other Identity fields are supported by the people picker feature. For example, when you choose the Assigned To field from within a work item form, the people picker is activated. As shown in the following image, you simply start typing the name of the user you want to select, and search until you find a match. Users that you've previously selected appear in the list automatically. To select users that you haven't selected previously, simply enter their entire name or search against the full directory.
For organizations that manage their users and groups using Azure Active Directory (Azure AD) or Active Directory, people pickers provide support for searching all users and groups added to the AD, not just those added to the project. To learn more, see Add AD/Azure AD users or groups to a built-in security group.
You can limit the values available to Identity fields within a work item by adding a custom rule.
Collection-level process customization
Your project determines the objects available to track work and the configuration of Agile tools. Specifically, the project determines the work item types (WITs)—user stories, tasks, bugs— and the data fields used to capture information. Customized objects are shared across teams added to the project.
Note
The method you use to customize work tracking depends on the process model you subscribe to:
- Inheritance: Supports WYSIWYG customization, available for Azure DevOps Services, Azure DevOps Server 2019, and Azure DevOps Server 2020.
- Hosted XML: Supports customization through import/export of process templates, available for a select number of customers of Azure DevOps Services who have opted into this model.
- On-premises XML: Supports customization through import/export of XML definition files for work tracking objects and is available for all on-premises deployments.
The following table summarizes the differences between the three supported process models. For definitions of the main work tracking objects, see Agile glossary. For links to all customization articles, see Quick reference index for Azure Boards settings.
Feature
WYSIWYG editing
✔️
Create inherited custom processes, Inherit changes in system processes (Agile, Basic, Scrum, CMMI)
✔️
Create custom process templates (see note 1)
✔️
✔️
Updated process changes automatically apply to all projects referencing the process
✔️
✔️
Support for customizing fields, work item types, form layout, workflow, custom rules, backlog levels, custom controls, test management
✔️
✔️
✔️
Support for customizing link types, team fields, global workflow, and process configuration (see note 3)
✔️
Initial configuration of Area paths, Iteration Paths, work item queries, security groups, and permissions (see note 3)
✔️
✔️
Global lists
Picklists
(see note 2)
✔️
Update Microsoft field mappings using the TFSFieldMapping command-line tool (see note 4)
✔️
✔️
Use the witadmin command-line tools to list and export process information
✔️
✔️
✔️
Use the witadmin command-line tools to edit process information
✔️
Use the tcm fieldmapping command-line tool to list and export test case management mapping for resolution types, bug filing, and failure types.
✔️
REST API (read)
✔️
✔️
✔️
REST API (write)
✔️
✔️
(see note 5)
Notes:
A process determines the building blocks used to track work. A process template specifies an interdependent-related set of XML definition files that provide the building blocks and initial configuration for tracking work and other functional areas.
Hosted XML customization supports adding and updating global lists with a process update (subject to limits on maximum size of each list). To learn more, see Work tracking object limits.
The Inherited process model doesn't support customization of the following features available with customization of process templates. Instead, you customize these areas within the web portal on a project-by-project basis.
- Configure Area Paths and Iteration Paths
- Work item queries
- Security groups and permissions
- Permissions and access to functional areas such as version control and build
Support for Office Project integration with Azure DevOps is deprecated starting with Azure DevOps Server 2019. The TFSFieldMapping command is not supported for Azure DevOps Server 2019 and later versions, including Azure DevOps Services. Starting with Visual Studio 2019, the Azure DevOps plug-in for Office no longer supports Office Project.
You can use the REST API to import and export process templates.
Customize the test experience
Several work item types support the test experience within the web portal Test pages and Test Manager client. You can customize these work item types—Test Plan, Test Suite, Test Case, Shared Steps, and Shared Parameters—as you would any other work item type.
The following image illustrates the supported link relationships.
See the following resources for additional usage and customization information:
- Test configurations and test variables
- Test resolution states (TFS)
- Failure types
- Define the initial test management configuration (process template)
- Query based on build and test integration fields
Less common customizations
You can only perform the following customizations when working with the Hosted XML or On-premises XML process models. Customizations made to process configuration apply to all teams added to a project.
Backlog and board limits (Hosted XML, On-premises XML)
To limit the display load time to acceptable parameters, the task board is restricted to a maximum of 1000 work items. For details, see Process configuration XML element reference.
You can increase this value up to a maximum of 1500 by specifying a value for the workItemCountLimit attribute of the TaskBacklog element. For details, see Process configuration XML element reference.
<TaskBacklog category="Microsoft.TaskCategory" pluralName="Tasks" singularName="Task" workItemCountLimit="800" >
. . .
</TaskBacklog>
Change field assignments (Hosted XML, On-premises XML)
You can change the work item fields that are used in calculating capacity, burndown charts, forecasting, and velocity. Any change you make to one of the default assignments should correspond to a change made to the WIT used to define and capture information for that value.
For example, if you change the refname assigned to type="Activity" then you should include the same field in the WIT definition assigned to the Task Category which captures the activity information. For details, see Process configuration XML element reference.
The fields you assign are used by the following tools:
| Tool | Field type |
|---|---|
| Task board, capacity tools, sprint burndown | Remaining work |
| Product and portfolio backlogs | Backlog priority |
| Velocity and forecast | Effort (maps to Story Points, Effort, or Size) |
| Task board, capacity tools | Remaining work |
| Capacity tools | Activity (Task Activity or Discipline) |
Grant or restrict access to work tracking tools
You can grant or restrict access to select features through permission settings. When you add user accounts to your team, they're automatically added to the Contributor group. They then have access to most of the features they'll need to contribute to code, work tracking, builds, and test. However, the Contributor group doesn't allow users to create shared queries or to add area or iteration paths. You have to grant these permissions separately.
For a simplified view of the most common, default permissions and access assignments, see Permissions and access. If you're new to managing permissions, see Get started with permissions, access, and security groups, Permission inheritance and security groups.
Otherwise, to grant or restrict access to select features, review one of these topics:
Manage access
Permissions
Shared resources
Additional customization options
Do you want to customize your tools in a way that's not supported?
Here are a few options available to you:
- Check out Marketplace extensions to see if there's a tool available for your purposes
- Develop your own extension
- Determine if a Service hook will satisfy your needs
- Create your own tool using REST APIs
- Add a feature request to our Developer Community page.