Customizing your Azure DevOps Experience

When you navigate to the Areas and Iterations section of your DevOps Administration you might have noticed a small blue bar at the top of the screen that indicates whether you would like to customize your work item types.

In previous incarnations of Azure DevOps, this was a painful exercise as you had to run these commands through Visual Studio or a command prompt. Now with Azure DevOps you can do many of these simple changes right from within the application itself.

Let’s say I want to add a new field to our bug layout that looks at where it came from (the Origin).

In this case, I click on the bug work item and when I arrive on the bug template page, I then click “New Field”.

When you look at the bug template you are going to notice that everything is grayed out and you can’t change anything, this is because you are trying to customize a system process and instead must “inherit” your changes from that process (essentially so whatever changes you make, don’t have negative consequences on base templates).

Now when I go to the bug customization page, I will see everything can be edited – what type I want my field to be, where I want it to go, is it required, etc.

The oddest part in this process is that there is no save button once you add the field (it is done magically behind the scenes).

Now if we navigate back to our DevOps project and go create a new bug, we’ll see that our new field is present and ready to go.

Note: In putting together this workflow, I completely forgot about the inheritance of templates and had to create a new project where I created an inherited process to then do my customizations from. Translation – Once you select an template for your DevOps project, you CANNOT change it, that’s life. If you are planning on implementing customizations, make sure you inherit from the base before you start working with that template.