Customize your work tracking experience

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022 | Azure DevOps Server 2020

As you plan and track your project, consider configuring features or customizing your experience to align with your team's tracking requirements. The approach for customizing projects, which affects all teams, depends on the process model you use.

This article gives you an overview of the customizations available and how they vary across the three process models. For specific guidance on customizations to support business decisions, see Configure and customize Azure Boards. For more information, see What is Azure Boards? and About work items.

Understanding customization levels

You can customize work tracking at the following levels:

Customization scope and impact

Understanding the scope of each customization level helps you make informed decisions:

Project-level shared resources

Each project provides many shared resources that support all teams within the project. You configure these features through the user interface or the admin context of the web portal.

Core shared resources

The following shared resources form the foundation of work tracking in your project:

• Area paths: Organize work items by feature area or team responsibility
• Iteration paths: Define sprints and releases for planning and tracking
• Shared queries: Create reusable queries that all team members can access
• Work item tags: Add metadata for categorization and filtering
• Security groups: Manage access permissions across the project

For more information, see the following articles:

• About area and iteration paths
• Set area paths
• Change the pick list for an iteration path
• Create and edit queries
• Add tags to work items

Best practices for shared resources

• Plan area paths early: Design your area path structure to reflect team ownership and product organization
• Establish iteration cadence: Set up consistent sprint lengths and release schedules
• Create folder structure: Organize shared queries in folders for better discoverability
• Use descriptive tags: Establish tagging conventions for consistent metadata
• Review permissions regularly: Ensure appropriate access levels for all team members

People picker and identity fields

The people picker feature supports identity fields throughout Azure DevOps:

• The Assigned To field and other Identity fields use the people picker feature.
• Activation: When you choose the Assigned To field within a work item form, the people picker activates automatically.
• User selection: To select a user, start entering their name and search until you find a match.
• Recent selections: Previously selected users appear automatically in the list for quick access.
• Directory integration: For organizations using Microsoft Entra ID or Active Directory, people pickers allow searching all users and groups added to the directory (not just ones added to a specific project).
• Scope limitation: To limit the scope of identities available for selection to project-specific users, use the Project-Scoped Users group.
• Custom restrictions: Custom rules can further restrict the values available for Identity fields within a work item.

Identity field configuration

You can configure identity fields in several ways:

• Project-scoped users: Limit identity selection to project members only
• Custom rules: Implement business rules that restrict field values
• Group-based restrictions: Use Azure AD groups to control available identities
• Field-level permissions: Set who can modify identity fields

For more information, see the following articles:

• Add Active Directory / Microsoft Entra users or groups to a built-in security group.

Your project defines the work item types (WITs) available for tracking work and configures Agile tools. It specifies user stories, tasks, bugs, and the data fields used to capture information. Customized objects are shared across teams within the project.

Process model comparison

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 customization articles, see Quick reference index for Azure Boards settings.

Process model selection guidance

Choose your process model based on your organization's needs:

Inheritance Process Model (Recommended)

• Best for: Teams wanting intuitive, web-based customization
• Advantages: WYSIWYG editing, automatic updates, easy maintenance
• Use when: You need moderate customization with minimal complexity

Hosted XML Process Model

• Best for: Organizations with complex process requirements
• Advantages: Full process template control, extensive customization
• Use when: You need advanced process customization but want cloud hosting

On-premises XML Process Model

• Best for: On-premises deployments with full control requirements
• Advantages: Complete customization flexibility, enterprise integration
• Use when: You need maximum control and run on-premises infrastructure

Notes:

1. 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.
2. Hosted XML customization supports adding and updating global lists with a process update (subject to limits on maximum size of each list). For more information, see Work tracking object limits.
3. 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.
   • Area and iteration paths
   • Work item queries
   • Security groups and permissions
   • Permissions and access to functional areas such as version control and build
   Or, you can use REST APIs.
   Or, you can use REST APIs or the Azure DevOps CLI command tool.
4. 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.

Inheritance process customization

For an Inherited process, you can customize the following work item types as you would any other work item type:

• Test Plan: Organize and manage test suites
• Test Suite: Group related test cases
• Test Case: Define individual test scenarios

On-premises XML customization

For an On-premises XML process, you can customize all test-related work item types, including:

• Test Plan: High-level test organization
• Test Suite: Test case groupings
• Test Case: Individual test definitions
• Shared Steps: Reusable test procedures
• Shared Parameters: Parameterized test data

Test work item relationships

The following example shows the supported link relationships between test work item types:

Test customization scenarios

Common test experience customizations include:

• Custom test fields: Add organization-specific test metadata
• Test workflow states: Define custom test execution states
• Test result tracking: Customize test outcome reporting
• Integration fields: Connect tests with requirements and defects

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 within 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 1,000 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>

Performance considerations for board limits

When customizing board limits, consider:

• Load time impact: Higher limits may increase page load times
• User experience: Balance functionality with performance
• Browser limitations: Some browsers handle large datasets differently
• Network bandwidth: Consider team members with slower connections

Change field assignments (Hosted XML, On-premises XML)

You can change the work item fields that the system uses 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 that captures the activity information. For details, see Process configuration XML element reference.

Tools that use field assignments

The fields you assign are used by the following tools:

Field assignment best practices

• Maintain consistency: Ensure field assignments match work item type definitions
• Test changes: Validate that tools work correctly after field reassignments
• Document customizations: Record field assignment changes for future reference
• Consider impact: Understand how changes affect existing data and reports

Manage access to work tracking tools

You manage access to specific 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 need to contribute to code, work tracking, builds, and testing. 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.

Default permission structure

The permission system operates on these principles:

• Default access: New team members automatically join the Contributor group
• Core permissions: The Contributor group provides access to most features needed for development work
• Additional permissions: Some features require separate permission grants
• Administrative access: Project administrators have full control over permissions

Contributor group limitations

The Contributor group doesn't automatically allow users to:

• Create shared queries: Requires additional query permissions
• Add area or iteration paths: Requires project-level administrative permissions
• Modify security settings: Requires administrative access
• Configure team settings: Requires team administrator role

Permission management approach

To effectively manage permissions:

1. Start with defaults: Use built-in groups as the foundation
2. Grant specific permissions: Add permissions for specific needs
3. Use security groups: Leverage Azure AD groups for easier management
4. Regular reviews: Periodically audit permissions for appropriateness
5. Document decisions: Maintain records of permission grants and rationale

For a simplified overview of common default permissions and access assignments, see Permissions and access.

If you're new to managing permissions, explore Get started with permissions, access, and security groups, Permission inheritance and security groups.

Specific permission areas

To manage access to specific features, see the following articles:

More customization options

Beyond the built-in customization features, consider these additional options for extending Azure DevOps functionality:

Marketplace extensions

• Browse solutions: Check out Marketplace extensions to see if there's a tool available for your purposes
• Popular categories: Look for extensions in work tracking, reporting, and project management
• Community contributions: Benefit from solutions developed by the Azure DevOps community

Custom development options

• Build extensions: Develop your own extension for specific organizational needs
• Integration tools: Create custom integrations using REST APIs
• Service hooks: Determine if a Service hook satisfies your automation needs

Community engagement

• Feature requests: Add a feature request to our Developer Community page
• User feedback: Share your experiences and suggestions with the product team
• Best practices: Learn from other organizations' customization approaches

Planning your customization strategy

Before implementing customizations, consider:

1. Business requirements: Clearly define what you want to achieve
2. Impact assessment: Understand how changes affect existing workflows
3. Maintenance overhead: Consider the long-term cost of maintaining customizations
4. Alternative solutions: Evaluate if existing features meet your needs
5. Migration path: Plan for future updates and migrations

Next steps

Related articles

• Work item field index
• witAdmin command-line tool
• Manage process templates
• Process templates overview
• Work tracking, process, and project limits
• Quick reference index for Azure Boards settings