Team Automation Rules
I have great news!
An Azure DevOps feature we have been waiting for since the TFS days is finally here.
Have you ever wanted your story to automatically update to active when its first task is activated, or have it close when it’s last task is closed. Same for Feature-Story, or Epic-Feature.
That is exactly what you can configure to happen with the new feature “Team Automation Rules”.
Here are the release notes, and here is the official documentation.
How does it work?
As the name implies “Team Automation Rules” has been implemented as a Team setting for each portfolio backlog level and the Requirement backlog. Therefore you can configure this for Epics, Features, Requirements, or a custom portfolio backlog level all separately.
The rules are configured at the team backlog level and are applicable to all work items at that specific level. This means that the Feature backlog can have distinct rules from the Requirement backlog.
The options are pretty simple.
As you can see there is special consideration for the resolved state. If you are using the Agile or CMMI process templates and would rather change your state to resolved instead of complete when all children are closed, you have that option.
How to configure a team to use Automation Rules?
Open your team’s backlog, and select the backlog level you want to configure. Click on the gear on the right to access Team Settings.
Under Team Settings you will see a new tab called Automation.
Now you just configure the automation the way you want it to behave.
State Category
To fully understand how this works we should talk about State Categories.
Team Automation Rules use State Categories instead of state directly. Partly because of our ability to add custom states and because each process template is configured differently.
Depending on your process, you may have more than one state assigned to a state category. The automation rule will default to the first state within the state category.
Other Notes
- Work Item Automation rules can only be changed by team admins or project admins.
- Work items must belong to the same team; closing a task in a different team or project will not trigger the closure of the parent item.
- Updates via REST APIs will not activate automation rules. However you can automate the updating of parent items by implementing additional patch updates.
- The Removed state is not taken into account at this point, fingers crossed it’s coming. What I would like to see is that these rules treat “Removed” the same as closed for the child work item. For example: If the last active child is removed, close the parent. Or if the parent has 1 removed child and one active child and you close the active child close the parent. I have asked for this, we’ll see.
