Managing State Transitions in Azure DevOps

A few weeks ago I wrote an article called Adding Approved Date/Approved By, where I explain how to add fields and use process rules to populate a date and user when an event occurs, like the Approval of a work item.

There are some small issues with that process change.

For example, what happens when someone changes the state back to Approved. Maybe it was committed to a sprint then the team changed their mind and set it back to approved. The Approved Date would change again and that is likely not what you want happening.

There is another rule we could have used to stop this from happening.

• Change the condition from: A work item state changes to…
• To use this condition: A work item state changes from …

Now you can select a specific from and to state.

However there is still the possibility that someone could change the state from approved back to new, and then back to approved which would trigger the rule and reset the approved date.

If that is not what you want, how about we stop people from changing the state from approved to new all together. Once it’s approved it can never be new again, right?

Try this rule for that scenario.

With this rule, when you select the state drop down on a work item that is approved, new is not an option.

As you can imagine it’s easy once you start adding rules to create new problems but there are usually ways around them.

Keep in mind when testing changes to process rules don’t do it to a live process. If you are not sure how to make these kinds of changes and test them before going live. You might want to check out this article. Responsibly Changing Azure DevOps Processes