Customization of Work Items in Azure DevOps and Azure DevOps Server 2020

Customization of Work Items in Azure DevOps and Azure DevOps Server 2020

When a development team starts working with Azure Boards service of Azure DevOps, some team members may realize that they need to configure some features to suite the team’s requirement. They may need to customize a feature so that the result can satisfy the needs of the process that is adopted, rather  than using an out of box functionality.

This leads to customization for various aspects in Azure DevOps, which is available as follows:

• Team level customization: Customize specific tools from team’s perspective like portfolio management
• Project level customization: Customize work item types (add or modify)
• Security access to team members: grant access or restrict access to work item tracking tools to team members

In this tutorial, I will be focusing on the second option which is how to do customization of work items types.

I will provide details about how to do customization in Azure DevOps. I will demonstrate how an inherited process can be used to change or add work item type with project specific needs. I will also provide a few glimpses of customization of work item types for on-premises version i.e. Azure DevOps Server 2020.

Customize Process in Azure DevOps

When we want to create a team project in Azure DevOps, we have four process  options to choose from – Basic, Agile, CMMI and Scrum.

A process defines the work items, their tracking and their behavior. We cannot customize any of the these out of box process, they always remain as they are, since many projects may depend upon them. If we want to customize a process, we need to inherit an existing process first. This will create a process that can be customized to suite our requirements. The system defined process may get an update from Microsoft, and this will be automatically updated to your inherited process.

Normally customization is done to add a work item type (WIT) or modify the existing work item type to suite our requirement. Work Item Type commonly called as WIT can be modified by adding new fields, changing layout, adding rules. We can even change the workflow of WIT.

Let us now find out how to create inherited process. I am taking Scrum as the base process, but the same can be applicable to other processes too. We will then add a new work item type called as Ticket to it. Let us provide a default value to the priority field of it and see how to add a rule which does not allow the value of that field to go beyond a limit.

Creating Inherited Process

I am assuming that the team is working as a maintenance team and because of which needs a particular work item of type Ticket. By default, Azure DevOps does not provide such work item. The work item also requires a priority for this ticket.

1. As a first step, we create a new organization in Azure DevOps. Follow these steps if you do not already have an organization. It is very easy to create an organization in Azure DevOps.

Use https://dev.azure.com link to create a free account. You can click on Start Free button to continue, use any Microsoft Live Account like outlook.com or Hotmail.com. You may even use your Gmail account if it is linked to your Microsoft account.

2. Once the account is ready, select the Organization Settings blade, select Process from Boards

3. Click on the ellipse button for Scrum Process to see the menu for inherited process.

Provide the name for the process and click on Create Process.

4. Now this inherited process is available for customization. Select the process to find if it is possible to create a new work item type. Provide name, select icon, color and click on Create.

Note: When you add a new Field, it is available to any other inherited process.

Adding a Field to Ticket

5. Adding a new field to the ticket is pretty simple. Click on New Field and provide the required details.

Provide the details for Options like whether the field is required and what is default value for it.

Provide the place where the new field should be displayed.

6. Now that the new field is added to the work item type, let us change the state transitions for the same. Select State tab and you will find the default states as follows:

Note: We need to provide category for the state. It is not possible to add a new Category. Be careful when you are removing any state if there are already existing work items.

Remember that for an existing work item, you can only add or hide existing states, you cannot remove any.

7. I have added one state as Escalated and changed Done to Resolved as follows:

8. We will now open the Rules tab and add a rule. I have added a rule which changes the value of ticket priority field to High automatically when the state is changed to Escalated.

9. Now it is time to create a Team Project based on the new Process and find out if the features are working as expected.

10. Now select Boards > New work Item and you get the newly added Work Item Type > Ticket

11. Create a new Ticket, change the state to Escalated and observe the rule changing the priority to High automatically.

Now that we have seen how to do customization for inherited process, let us find out how XML process can be created for a collection in Azure DevOps Server 2020 and how the template can be exported for customization.

XML Process for a Collection in Azure DevOps Server 2020

The collection concept is still available for on premises functionality – Azure DevOps Server 2020.

We can start Azure DevOps Server Administration Console and select the option for Create Collection. Collection was introduced in TFS 2010 so as to provide isolation of data stored for different collections. Each collection can create a new database on SQL Server.

Observe the two different ways to create Team Project Collection in the diagram above. The XML collection as shown is based on the legacy process which is available for many years.

There is a separate extension available with Visual Studio for the Process Editor. This provides the same functionality as earlier.

Let us find out the steps for doing customization to the work item and the process.

12. Select the Collection Settings for the collection created with XML process, select Process under Boards and click on ellipse to get following options:

You can view the Export option which will download the complete information for the process. The following folder structure is observed:

13. Once the extension is installed, we can open ProcessTemplate.xml from Visual Studio to do modifications.

14. Once the process is opened in editor, we can do the required changes to work item type definitions or wherever applicable, and save the file(s). Create a zip file which can be uploaded to use for the customized process.

Note: Do not forget to change the name of the process and the GUID of it. The name can be changed in the Visual Studio Process Editor, but GUID needs to be changed by opening an XML file separately.

15. It is possible to change the existing definitions of these work items if needed.

Note: This functionality is different than the inherited template.

16. A new field can be created, which needs to have a reference name. The type of the field can be selected from the given types like string, integer, double, date time, text, HTML, tree path, history or Boolean.

Note: The new field does not get added automatically to the Web UI. When we open the work item, we do not find it there. We need to add information related to this new field to the WebLayout tag.

Once the customized process is uploaded, it looks as follows

Observe that this process is not locked like all others are.

These customized processes can help in bridging the gap between the expectations and features available with either Azure DevOps or Azure DevOps Server.

This xml process is available in Azure DevOps Server but is it possible to have it in Azure DevOps?

The answer is not straight forward. If you have migrated from Team Foundation Server (TFS)/ Azure DevOps Server to Azure DevOps and you had selected the option of this xml template earlier, then after migration, you will get the process in Azure DevOps. But if you are creating a new account/ organization with Azure DevOps, the option is not available.

Conclusion

In this tutorial, I discussed the need of customization of process along with creation of new work item. I also discussed how a new field can be added with the rules if required.

There is a difference between the customization process in Azure DevOps and the on-premises Azure DevOps Server. An existing work item type can be modified in Azure DevOps Server.

This article was technically reviewed by Subodh Sohoni.