Prevent reopening work item once closed | Azure DevOps (with Video)

Controlling the process manually is challenging

Enforcing process is hard when there are many people within the team using task management tool like Azure DevOps. I have a process that once a work item is closed then it should not be reopened even if it was allowed in Azure DevOps. People tend to forget the process and in the sense of urgency and/or their convenience, they just override the protocols by doing what they want to. I don’t blame anyone. Thankfully, you can control the process of work items in Azure DevOps through setting a few rules for your work item types in Azure DevOps process settings. The tip below provides step-by-step guidance on how to lock or freeze closed work items using Rules in Azure DevOps settings to control your DevOps process. It uses a hack that is called out below.

Why prevent reopening a task after it’s closed

The short answer is to have a better control on processes and workflows. It also helps provide more accurate team utilization metrics using Azure DevOps for reporting on or analyzing operations. For example, let’s say that a task is submitted to update a page’s content and once all of that is processed and the task status is set to closed, task requestor may reuse the same task to carry out further updates. Using the same task item for iterative updates can incorrectly reflect either the time taken by resources to close the task or total number of tasks processed within a month by the team. Hence, a control through the system is needed.

Reopening a task from “Resolved” (vs. Closed) state is still often allowed but after a no response for a set time like 24 or 48 hours (varies by teams and organizations), tasks are typically closed and should be locked. Freezing a task from reopening, once its status is set to “Closed”, enforces the users to submit a new work item for further updates instead of requesting the updates through the same closed task.

Solution – How to set up rules to prevent reopening of work items in Azure DevOps

You can watch the video below to see it in action but if you want to go old school method, keep reading below.

  1. Go to the process page at{org-name}/_settings/process.
  2. Go to your inherited process that contains the work item for which you want to apply this rule.
    Rules are allowed only in inherited process for work items. See manage process on Azure DevOps.
  3. Once you are on the inherited process page, click on the work item that you want to set rules for. In our example, it is the Bug work item.
  4. Click on Rules tab and then click “New rule”
  5. Set below rules iteratively until rules are created for all states other than the “Closed” state.
    1. Name: “Prevent Closed to New”
    2. Condition: When — “A work item state changes from” — “Closed” — to — “New”
    3. Action: “Make read only” — “System.State” (this will show you a validation error but go ahead and save it!) This is the hack.
      Screenshot of Azure DevOps process setting showing an example condition and action that are described in the instructions
    4. Do the above for each of the states that you want to lock from changing from “Closed”.
  6. Finally, add a rule below to lock fields when state is Closed:
    1. Name: “Lock Fields when Bug is Closed”
    2. Condition: When “A work item state is” — “Closed”
    3. Actions: Set “Make read only” for each of the fields. In my example of the Bug work item, I set this action for “Title” and “Repro Steps”.
  7. You are all set!

This should now prevent changing of title and/or repro steps field of any Bug work item when it is in Closed state while also preserving the state once it is closed.

If you run into any issues, ask via comments or watch the video above to see it in action.


Consider reading:

3 Comments on "Prevent reopening work item once closed | Azure DevOps (with Video)"

  1. Is there any way to prevent “undesirable” states from being seen? I am in the process of migrating from JIRA to DevOps. We’re using JIRA to document the SDLC including users approval to begin work, promote to production, etc. Not all of these users are “computer-savvy” and will be confused/irritated if they have to select a State from a large list where only one state will work instead of simply clicking the only button that is available. I’ve tried using the “A work item state is moved from” condition and “Restrict the transition to state” action, but this didn’t work. Any ideas?

  2. Thank you for the hack. but what if I have this work item in my product deprecated or removed from the live product?
    Example: manual registration removed, and the registration is using social logins and LDAP- so the manual registration is completely removed. New story has been created for this new registration, what about the removed one? it is part of live product list ? it should updated with us for any future regression..etc.

    What do you think?

    • @Ahmad Why would you be concerned about a work item that is removed? I am not sure how your manual registration work item fits into the overall DevOps structure so perhaps a bit more context would help in what you are trying to solve.

Leave a comment

Your email address will not be published.