Edit

Share via


Quickstart: Add a custom work item type (Inheritance process)

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

In this quickstart, you create a custom work item type (WIT). In Azure Boards, You use different work item types to plan and track different types of work. The main reason you add a custom WIT is to customize the web form and workflow states to meet specific business use cases. Or, you can customize an existing WIT. Your project contains 9 or more WITs that you can customize, based on the process used to create your project.

Important

The Inheritance process model is available for projects that are configured to support the model type. If you use an older collection, check the process model compatibility. If your on-premises collection is configured to use the on-premises XML process model, you can only use that process model to customize the work tracking experience. For more information, see Organization-level process customization.

For example, you might want to capture customer issues in a custom WIT labeled Ticket.

Screenshot shows a custom Ticket work item form.

To learn more about what you can customize, see About process customization and inherited processes.

Tip

To customize a single project, always start by creating an inherited process and migrating projects to that process. Then, all the customizations that you make to the inherited process automatically appear for the project you migrated.

Prerequisites

For guidance on tailoring Azure Boards to align with your specific business requirements, see Configure and customize Azure Boards.

Category Requirements
Permissions - To create, delete, or edit a process: Member of the Project Collection Administrators group or specific collection-level permissions Create process, Delete process, Edit process, or Delete a field from organization set to Allow. For more information, see Customize an inherited process.
- To update boards: Team Administrator or a member of the Project Administrators group.
Access - Even if you have Basic or lower access, you can still change a process if someone gives you permission.
- To update and change the type of your existing work items: Member of the project.
Project process model - Have the Inheritance process model for the project collection containing the project.
- To migrate data to Azure DevOps Services, use the Team Foundation Server Database Import Service.
Knowledge - Familiarity with the customization and process models.

Open organization process settings

  1. Sign in to your organization (https://dev.azure.com/{yourorganization}).

  2. Select Organization settings.

    Screenshot showing Organization settings button for selection.

  3. Select Process.

    Screenshot showing highlighted Process button for selection.

  1. Sign in to your collection (https://dev.azure.com/{Your_Collection}).

  2. Select Collection Settings or Admin settings.

  3. Select Process.

    Screenshot showing highlighted Process button in Collection settings.

Create inherited process

For more information, see Create inherited process.

Add a work item type

  1. From the Work Item Types page, choose the New work item type.

    Screenshot shows the All processes page for the MyAgile process, with Add new work item type highlighted.

  2. Name the WIT and optionally specify a description, icon, and color. The icon and color you specify appear throughout the web portal, including on the work item form and when associated work items appear on a backlog, boards, and query results.

    Screenshot shows Create new work item type dialog where you can enter a name and other values.

    Choose Create to save.

    Each new WIT comes predefined with a Details page with the Description field, and Discussion, Development, and Related Work groups. Standard elements are also added, but not shown or editable. These elements are included with the header of the form as shown in the following image, and the history, links, and attachment pages. For more information, see About work items.

    Screenshot shows the WIT header details for the new work item.

  3. Name the field and select the field type from one of the supported data types. Field names must be unique and no more than 128 characters. For other restrictions, see What is a field? How are field names used? Optionally, add a description.

    This example adds an Integer field labeled Customer Ticket.

    Screenshot shows the Create a field option for a Bug.

    Other data types you can add include: Picklist, Identity, Rich-text, HTML, and Checkbox.

  4. (Optional) On the Options tab, indicate if the field is required. Specify a default value.

    Screenshot shows the Options page where you can make the field required and specify a default value.

    If a field is required, users must specify a value for the field in order to save it. The default value you specify is set when you create a work item and every time a work item is opened and the field is empty.

  5. (Optional) On the Layout tab, you can enter a different form label than the name of the field. Also, you can choose the page and group where the field appears on the form.

    This example adds a new field. Choose the (New Field icon).

    Screenshot shows the new field option for your new Ticket work item.

  6. Here, we add the Customer Ticket field to a new group labeled Customer focus.

    Screenshot shows the Layout page where you can specify how the field is displayed.

  7. Choose Add field to complete adding the field. If you didn't specify its layout location, it gets added to the first group of fields on the layout form.

    Tip

    After you add a field, you can drag-and-drop it within a page to relocate it on the form. If you have several fields you want to add to a custom page or group, add those elements first and then add your fields.

Verify the customization you made

We recommend that you create a test project and apply your customized inherited process to it to verify the changes you made.

  1. Open the All processes page, and choose the … context menu for the process you want to use. Then select New team project.

    Screenshot shows the Create a project option for a selected process.

    Screenshot shows the Create a project option for your modified process.

  2. The Create new project page opens. Fill out the form.

    Screenshot shows the Create new project form.

    Screenshot shows the Create new project page.

  3. Open Work Items. Select your project, then choose Work > Work Items.

    Screenshot shows Azure Boards with Work items selected.

  4. Select the WIT you customized, in this example, Ticket.

    Screenshot shows Work Items with New Work Item selected and the custom Ticket item highlighted.

    If you don't see the custom WIT, refresh your browser to make sure it registers all the custom changes.

  5. Verify that the field you added appears on the form. The (exclamation mark) icon indicates the field is required.

    Screenshot shows the Ticket form, with the Customer Ticket field added in the Customer Focus group.

Apply the customized process to your project

After you verify your customizations, you can now apply the process to your existing project.

Tip

As you customize a WIT, all projects that reference the inherited process automatically update to reflect the custom WITs you added. To view your customizations, refresh your web browser.

  1. For the process currently used by the project, choose the number of the project.

    This is the Agile default process.

    Screenshot shows the number for the team project, as a link.

  2. Open the … context menu for the project you want to change, and choose the Change process option.

    This is MyFirstProject1.

    Screenshot shows the project created with the Change process option.

  3. From the Change the project process dialog, choose the process from the menu of options. And, then choose Save.

    Screenshot shows the Change the project process dialog with Agile Inherited selected.

Q & A

Q: How do I get my custom work item type to show up on my backlog?

A: Modify your requirement backlog to include the custom work item type. For more information, see Edit or rename the requirement backlog.

Note

The backlog level to which you add a custom work item type determines the parent work item types for the work item type.

Next step

Note

You can review changes made to an inherited process by using the audit log and auditing features. For more information, see Access, export, and filter audit logs.