Skip to content

Latest commit

 

History

History
878 lines (766 loc) · 33.3 KB

query-by-workflow-changes.md

File metadata and controls

878 lines (766 loc) · 33.3 KB
title titleSuffix description ms.custom ms.service ms.assetid ms.author author ms.topic monikerRange ms.date
Query by account, user, workflow, or board changes in Azure Boards
Azure Boards
Learn how to list work items based on changes made to their assignment, state, or Kanban board column or swimlane in Azure Boards.
boards-queries
azure-devops-boards
1FD042F2-D503-40A3-A6C7-1E25A0F664C6
chcomley
chcomley
example-scenario
<= azure-devops
06/29/2022

Query by assignment or workflow changes in Azure Boards

[!INCLUDE version-lt-eq-azure-devops]

The states in the workflow support tracking work status as it moves from a new state to a closed or done state. Kanban query fields support tracking the status of work as it moves from one column or swimlane to another on the Kanban board.

Each workflow consists of a set of states, valid transitions between states, and reasons for transitioning the work item to the selected state. Workflow states and reasons differ among the work item types and default processes used to create your project.

Most work items move from a New, Active, or Proposed state to a Done or Closed state. As each work item moves from one state to another, the item might also be reassigned to various members of the team. For example, a tester might create a bug that is assigned to another team member during triage. When the other team member resolves the bug, it's reassigned to the tester who created it.

For example, you can find all work items that were closed but then reactivated. By specifying the Changed Date field, you can focus on reactivations that occurred today, yesterday, or in the last week.

Query Editor filter for reactivated items.

You can also use the Activated By and Activated Date fields, or other workflow fields.

Tip

Not all fields are valid for all work item types. Jump to Workflow and Kanban query fields for the set of fields you can include in queries and which work item types they apply to.

If you're new to creating queries, see Use the query editor to list and manage queries.

Supported operators and macros

Query clauses that specify an identity or workflow-associated field can use the operators and macros listed in the following table. To learn about the field data type, see Workflow and Kanban board fields provided later in this article.

:::row::: :::column span="1"::: Data type :::column-end::: :::column span="3"::: Supported operators and macros :::column-end::: :::row-end:::

:::row::: :::column span="1"::: Boolean 1 :::column-end::: :::column span="3"::: = , <> , =[Field] , <>[Field] :::column-end::: :::row-end:::

:::row::: :::column span="1"::: DateTime :::column-end::: :::column span="3"::: = , <> , > , < , >= , <= , =[Field], <>[Field], >[Field], <[Field], >=[Field], <=[Field], In, Not In, Was Ever
Macros: @Today, @Today +/- n valid with any DateTime field :::column-end::: :::row-end:::

:::row::: :::column span="1"::: Identity :::column-end::: :::column span="3"::: = , <> , > , < , >= , <= , =[Field], <>[Field], >[Field], <[Field], >=[Field], <=[Field], Contains, Does Not Contain, In, Not In, In Group, Not In Group, Was Ever Macros: @Me valid for all Identity fields :::column-end::: :::row-end:::

:::row::: :::column span="1"::: Single text (String) 2 :::column-end::: :::column span="3"::: = , <> , > , < , >= , <= , =[Field], <>[Field], >[Field], <[Field], >=[Field], <=[Field], Contains, Does Not Contain, In, Not In, In Group, Not In Group, Was Ever :::column-end::: :::row-end:::

Use the In and Not In operators to filter for or exclude two or more pick list entries or a delimited set of items. Use the In Group or Not In Group operators to filter for items that belong or don't belong within a category group or security group. For more information, see Query fields, operators, and macros.

[!INCLUDE date-time-pattern]

Identity-based queries

Use the search box or query editor to quickly find work items based on an assignment made to an Identity field. Also, you can filter for work items based on who changed, resolved, or closed a work item. By specifying a time period, you can scope your query even further, which can help with performance.

Use = to find current assignments, Was Ever to list items based on past assignments, and @Me to scope to your user identity.

:::row::: :::column span="1"::: Filter for :::column-end::: :::column span="1"::: Include these query clauses :::column-end::: :::row-end:::

:::row::: :::column span="1"::: Active items assigned to me :::column-end::: :::column span="1"::: Assigned To @Me
And State = Active
:::column-end::: :::row-end::: :::row::: :::column span="1"::: Closed items that at some point was assigned to me :::column-end::: :::column span="1"::: Assigned To Was Ever @Me
And State = Closed :::column-end::: :::row-end::: :::row::: :::column span="1"::: Active user stories assigned to the Web team :::column-end::: :::column span="1"::: Work Item Type = User Story
And State = Active
And Assigned To In Group [FabrikamFiber]\Web :::column-end::: :::row-end::: :::row::: :::column span="1"::: Items I've modified in the last 30 days :::column-end::: :::column span="1"::: Changed By = @Me And Changed Date >= @Today-30 :::column-end::: :::row-end::: :::row::: :::column span="1"::: Unassigned items (leave the Value blank) :::column-end::: :::column span="1"::: Assigned To = _ :::column-end::: :::row-end:::

Team or group membership queries

To filter on items assigned to someone who belongs to a team or security group, use the In Group operator.

Screenshot of Query Editor, Filter based on assignment to a security group.

You can use the In Group or Not In Group operators to filter a query based on several values that are members of a group, or that aren't members of a group. Examples of groups you can specify include the following items:

  • Teams
  • Built-in and custom security groups
  • Microsoft Entra ID and Active Directory security groups
  • Work item categories

Queries based on workflow changes

You use the State, Reason, and Resolved Reason fields to query for items based on workflow changes.

:::row::: :::column span="1"::: Filter for :::column-end::: :::column span="1"::: Include these query clauses :::column-end::: :::row-end:::

:::row::: :::column span="1"::: Resolved stories :::column-end::: :::column span="1"::: Work Item Type = User Story
And State = Resolved :::column-end::: :::row-end::: :::row::: :::column span="1"::: Stories, bugs, and tasks that are new or active :::column-end::: :::column span="1"::: Work Item Type In User Story,Bug,Task
And State In New,Active :::column-end::: :::row-end::: :::row::: :::column span="1"::: Items removed as they're duplicate
:::column-end::: :::column span="1"::: State= Removed
And Reason = Duplicate :::column-end::: :::row-end::: :::row::: :::column span="1"::: Items failing acceptance tests
:::column-end::: :::column span="1"::: Resolved Reason = Acceptance tests fail :::column-end::: :::row-end::: :::row::: :::column span="1"::: Items closed within the last 15 days
:::column-end::: :::column span="1"::: State = Closed
And Closed Date > @Today-15 :::column-end::: :::row-end:::

Workflow changes and identity-based queries

You can quickly find items that you changed, resolved, or closed. You can also find items that were changed by other team members. Several fields—such as the Created By, Changed By, Resolved By, and Closed By—are populated based on changes to the workflow.

:::row::: :::column span="1"::: Filter for :::column-end::: :::column span="1"::: Include these query clauses :::column-end::: :::row-end:::

:::row::: :::column span="1"::: User Stories that I closed :::column-end::: :::column span="1"::: Work Item Type = User Story
And Closed By = @Me :::column-end::: :::row-end::: :::row::: :::column span="1"::: Items I resolved in the last week :::column-end::: :::column span="1"::: Resolved By = @Me
And Resolved Date >= Today-7
:::column-end::: :::row-end:::

Query changes in work item state

To list work items that have changed state within a specific date range, you can use the State Change Date field to narrow the search and then add clauses for changes to the State field. An example is shown in the following image.

[!div class="mx-imgBorder"] Screenshot of Query Editor, filter State Change Date and State fields.

Query changes to a Kanban board

Using the Kanban query fields—Board Column, Board Column Done, and Board Lane—you can list work items according to their flow status on the Kanban board. And, you can create a status or trend chart based on these queries.

You can list items based on the team area path, and if they are in a specific custom Kanban column and swimlane. If you rename a column or swimlane, you'll need to update the query filters to reflect the new name. For more ideas, see this blog post: New fields bring Kanban goodness to queries, and more

Screenshot of Query Editor, filter on Kanban Board Column and Board Lane fields.

Note

Queries are now scoped to the current project by default. Check the Query across projects to find work items defined in other projects within the collection.

:::row::: :::column span="2"::: Filter for :::column-end::: :::column span="2"::: Include these query clauses :::column-end::: :::row-end:::

:::row::: :::column span="2"::: User Stories in the Code/Doing column :::column-end::: :::column span="2"::: Work Item Type = User Story
And Board Column = Code
And Board Column Done = False
:::column-end::: :::row-end::: :::row::: :::column span="2"::: Items in the Expedite swimlane :::column-end::: :::column span="2"::: Board Lane = Expedite
:::column-end::: :::row-end::: :::row::: :::column span="2"::: Items in any swimlane whose label contains "Test"
:::column-end::: :::column span="2"::: Board Lane Contains Test
:::column-end::: :::row-end::: ::: moniker range="azure-devops" :::row::: :::column span="2"::: Items that were ever in the "In Review" column :::column-end::: :::column span="2"::: Board Column Was Ever In Review
:::column-end::: :::row-end::: ::: moniker-end

[!INCLUDE temp]

Workflow and Kanban board fields

The following fields are useful to filter queries. Some of these fields get updated as a work item progresses from one state to another. Or they're updated as you move a work item in the Kanban board to a different column or swimlane. Several of these fields don't appear on the work item form, but they're tracked for those work item types listed in the following table.

For more information about field attributes, see Work item fields and attributes.

:::row::: :::column span="1"::: Field name :::column-end::: :::column span="2"::: Description :::column-end::: :::column span="1"::: Work item type :::column-end::: :::row-end:::

:::row::: :::column span="1"::: Activated By 1, 2, 3 :::column-end::: :::column span="2"::: ::: moniker range="azure-devops" The name of the team member who changed the status of a work item to an In Progress category state. ::: moniker-end ::: moniker range="< azure-devops" The name of the team member who changed the status of a work item from New to Active or reactivated a work item after it had been closed, completed, or done. ::: moniker-end Reference name=Microsoft.VSTS.Common.ActivatedBy
Data type=String (Identity) :::column-end::: :::column span="1"::: Bug, Change Request, Epic, Feature, Issue, Product Backlog Item, Requirement, Review, Risk, Shared Step, Task, Test Case, User Story :::column-end::: :::row-end::: :::row::: :::column span="1"::: Activated Date 1, 3 :::column-end::: :::column span="2"::: ::: moniker range="azure-devops" The date and time when the work item was changed to an In Progress category state. ::: moniker-end ::: moniker range="< azure-devops" The date and time when the work item was changed from New to Active or reactivated after it had been closed, completed, or done. ::: moniker-end Reference name=Microsoft.VSTS.Common.ActivatedDate
Data type=DateTime :::column-end::: :::column span="1"::: All :::column-end::: :::row-end::: :::row::: :::column span="1"::: ::: moniker range="azure-devops" Assigned To  2 ::: moniker-end ::: moniker range="< azure-devops" Assigned To  2, 3, 4 ::: moniker-end :::column-end::: :::column span="2"::: The name of the team member who currently owns the work item. For more information, see Note 1 on synchronization and person-name fields.

  Reference name=`System.AssignedTo`  
  Data type=String (Identity)

:::column-end::: :::column span="1"::: All :::column-end::: :::row-end::: :::row::: :::column span="1"::: Board Column :::column-end::: :::column span="2"::: The current Kanban board column assignment of the work item, for example: Active, Closed, Committed, Done, or other custom column assignment.

  Reference name=`System.BoardColumn`  
  Data type=String

:::column-end::: :::column span="1"::: ::: moniker range="azure-devops" Requirement Category 4
::: moniker-end ::: moniker range="< azure-devops" Requirement Category 5 ::: moniker-end :::column-end::: :::row-end::: :::row::: :::column span="1"::: Board Column Done :::column-end::: :::column span="2"::: The current assignment of the work item to Doing (False) or Done (True) Kanban column. Only assigned when split-columns is enabled for a Kanban board column.

  Reference name=`System.BoardColumnDone`  
  Data type=Boolean

:::column-end::: :::column span="1"::: ::: moniker range="azure-devops" Requirement Category 4
::: moniker-end ::: moniker range="< azure-devops" Requirement Category 5 ::: moniker-end :::column-end::: :::row-end::: :::row::: :::column span="1"::: Board Lane :::column-end::: :::column span="2"::: The current Kanban board swimlane assignment of the work item, for example: Default, Expedite, Blocked, or other custom swimlane assignment. Reference name=System.BoardLane
Data type=String
:::column-end::: :::column span="1"::: ::: moniker range="azure-devops" Requirement Category 4
::: moniker-end ::: moniker range="< azure-devops" Requirement Category 5 ::: moniker-end :::column-end::: :::row-end::: :::row::: :::column span="1"::: ::: moniker range="azure-devops" Closed By 1, 2 ::: moniker-end ::: moniker range="< azure-devops" Closed By 1, 2, 3 ::: moniker-end :::column-end::: :::column span="2"::: The name of the team member who set the state to closed, completed, or done.

  Reference name=`Microsoft.VSTS.Common.ClosedBy`  
  Data type=String (Identity)

:::column-end::: :::column span="1"::: All :::column-end::: :::row-end::: :::row::: :::column span="1"::: Closed Date :::column-end::: :::column span="2"::: The date and time when a work item was closed.

  Reference name=`Microsoft.VSTS.Common.ClosedDate`  
  Data type=DateTime

:::column-end::: :::column span="1"::: All :::column-end::: :::row-end::: :::row::: :::column span="1"::: ::: moniker range="azure-devops" Created By 1, 2 ::: moniker-end ::: moniker range="< azure-devops" Created By 1, 2, 3 ::: moniker-end :::column-end::: :::column span="2"::: The name of the team member who created the work item.

  Reference name=`System.CreatedBy  
  Data type=String (Identity)

:::column-end::: :::column span="1"::: All :::column-end::: :::row-end::: :::row::: :::column span="1"::: Created Date :::column-end::: :::column span="2"::: The date and time when a work item was created.

  Reference name=`System.CreatedDate`  
  Data type=DateTime

:::column-end::: :::column span="1"::: All :::column-end::: :::row-end::: :::row::: :::column span="1"::: ::: moniker range="azure-devops" Reason ::: moniker-end ::: moniker range="< azure-devops" Reason 3, 4 ::: moniker-end :::column-end::: :::column span="2"::: The reason why the work item is in the current state. Each transition from one workflow state to another is associated with a corresponding reason.
::: moniker range="< azure-devops-2019" For On-premises XML process models, the reason values are defined within the WORKFLOW section of the work item type definition using the REASON element. To modify the defined reasons, see Change the workflow for a work item type. ::: moniker-end Reference name=System.Reason
Data type=String :::column-end::: :::column span="1"::: All (except Test Case and Shared Steps) :::column-end::: :::row-end::: :::row::: :::column span="1"::: ::: moniker range="azure-devops" Resolved By 1, 2
::: moniker-end ::: moniker range="< azure-devops" Resolved By 1, 2, 3
::: moniker-end :::column-end::: :::column span="2"::: ::: moniker range="azure-devops" The name of the team member who changed the status of a work item to a Resolved category state. ::: moniker-end ::: moniker range="< azure-devops" The name of the team member who changed the status of a work item to Resolved or done workflow state. ::: moniker-end Reference name=Microsoft.VSTS.Common.ResolvedBy, Data type=String (Identity) :::column-end::: :::column span="1"::: All :::column-end::: :::row-end::: :::row::: :::column span="1"::: ::: moniker range="azure-devops" Resolved Date ::: moniker-end ::: moniker range="< azure-devops" Resolved Date 1, 2 ::: moniker-end :::column-end::: :::column span="2"::: ::: moniker range="azure-devops" The date and time when the work item was changed to an In Resolved category state. ::: moniker-end ::: moniker range="< azure-devops" The date and time when the work item was moved into a Resolved or done workflow state. ::: moniker-end Reference name=Microsoft.VSTS.Common.ResolvedDate, Data type=DateTime :::column-end::: :::column span="1"::: All :::column-end::: :::row-end::: :::row::: :::column span="1"::: ::: moniker range="azure-devops" Resolved Reason ::: moniker-end ::: moniker range="< azure-devops" Resolved Reason 3 ::: moniker-end :::column-end::: :::column span="2"::: The reason why a work item was resolved. For example, the user story is code complete or the bug is fixed. This field is read-only and only valid for Agile and CMMI work item types.

  Reference name=`Microsoft.VSTS.Common.ResolvedReason`  
  Data type=String

:::column-end::: :::column span="1"::: All (Agile, CMMI) :::column-end::: :::row-end::: :::row::: :::column span="1"::: Reviewed By :::column-end::: :::column span="2"::: The name of the team member who responded to a code review request and is cataloged in the code review response.

  Reference name=`Microsoft.VSTS.Common.ReviewedBy`  
  Data type=String (Identity)

:::column-end::: :::column span="1"::: Code Review Response :::column-end::: :::row-end::: :::row::: :::column span="1"::: ::: moniker range="azure-devops" State
::: moniker-end ::: moniker range="< azure-devops" State 3, 4 ::: moniker-end :::column-end::: :::column span="2"::: The current state of the work item. This field allows you to update the status of a work item as it progresses from new or active to a done or closed state.
::: moniker range="azure-devops" To modify the workflow states, see Customize the workflow for a process. ::: moniker-end ::: moniker range=">= azure-devops-2019 < azure-devops" To modify the workflow states, see the following articles:
- For Inherited process model: see Customize the workflow for a process - For On-premises XML process models: see Change the workflow for a work item type. ::: moniker-end ::: moniker range="< azure-devops-2019" To modify the workflow states, see Change the workflow for a work item type. ::: moniker-end
Reference name=System.State
Data type=String :::column-end::: :::column span="1"::: All :::column-end::: :::row-end::: :::row::: :::column span="1"::: State Changed Date :::column-end::: :::column span="2"::: The date and time when the value of the State field changed.

  Reference name=`Microsoft.VSTS.Common.StateChangeDate`  
  Data type=DateTime

:::column-end::: :::column span="1"::: All :::column-end::: :::row-end:::

::: moniker range="azure-devops"

Note

  1. See Date and Identity fields.
  2. By default, the server synchronizes system-defined person-name or Identity-based fields with Active Directory or Microsoft Entra ID. These fields include: Activated By, Assigned To, Closed By, Created By, and Resolved By. You can grant access to a project by adding security groups that you created in Active Directory or Microsoft Entra ID or by adding accounts to existing or custom groups defined from the collection setting Security page. See set up Active Directory or Microsoft Entra ID.
  3. See Activated By/Date and Resolved By/Date fields.
  4. The Requirement Category applies to all work item types that appear on the product backlog and Kanban board, and may include those added to the Bug Category based on the team setting for Show bugs on boards and backlogs. For more information on work item type categories, see Use categories to group work item types.

Note

Even if you add a board-related field, such as Board Column or Board Lane, to a work item form, you can't modify the field from the form.

::: moniker-end

::: moniker range="< azure-devops"

  1. See Date and Identity fields.

  2. By default, the server synchronizes system-defined person-name or Identity-based fields with Active Directory or Microsoft Entra ID. These fields include: Activated By, Assigned To, Closed By, Created By, and Resolved By. You can grant access to a project by adding security groups that you created in Active Directory or Microsoft Entra ID or by adding accounts to existing or custom groups defined from the collection setting Security page. See set up Active Directory or Microsoft Entra ID.

    For on-premises deployments, you can enable or disable synchronization for a person-name field by using the witadmin changefields command-line tool. You can also synchronize custom person-name fields by specifying the syncnamechanges attribute. See Manage work item fields and FIELD (Definition) element reference.

  3. Reportable field with attribute set to Dimension. Only valid when the collection is configured to support the On-premises XML model. Reportable data is exported to the data warehouse and can be included in Excel or SQL Server reports. For on-premises Azure DevOps, use the witadmin changefield command to change the reportable attribute for a field.

  4. Indexed field. Enabling indexing for a field may increase the performance of finding work items whose queries specify that field. For on-premises Azure DevOps, use the witadmin indexfield command to change the index attribute for a field.

  5. The Requirement Category applies to all work item types that appear on the product backlog and Kanban board. The category includes those items added to the Bug Category based on the team setting for Show bugs on boards and backlogs. For more information on work item type categories, see Use categories to group work item types.

Note

Even if you add a board-related field, such as Board Column or Board Lane, to a work item form, you can't modify the field from the form.

::: moniker-end

People picker

The Assigned To field is supported by the people picker feature. For example, when you choose the Assigned To field from within a work item form, the people picker is activated. As shown in the following image, you simply start entering the name of the user you want to select, and search until you find a match. Users that you've previously selected appear in the list automatically. To select users that you haven't selected previously, enter their entire name or search against the full directory.

[!div class="mx-imgBorder"]
Screenshot of the @mention tool in Discussion showing people picker.

For organizations that manage their users and groups using Microsoft Entra ID or Active Directory, people pickers provide support for searching all users and groups added to the AD, not just those users and groups added to the project.

::: moniker range="azure-devops"

To limit the scope of identities available for selection to just those users added to the project, you can do so using the Project-Scoped Users group. For more information, see Manage your organization, Limit identity search and selection.

::: moniker-end

Date and identity fields

Several date and identity fields are set based on workflow states or transitions. Some fields, such as Created By and Created Date, are set by the system when a work item is added. Other fields, such as Closed Date and Closed By, are set through the workflow definition of the work item type. Additionally, customized work item types may have other rules defined that influence the date and identity field assignments.

[!INCLUDE date-time-pattern]

::: moniker range="< azure-devops"

State changes

The following XML syntax example illustrates rules that may be defined for a work item type that govern the values for select fields. Here, the Resolved Date, Resolved By, Closed Date, Closed By, Activated Date, and Activated By fields are set to EMPTY when a State value is set to New. The State value assignments are evaluated first, and then the transition assignments are evaluated next.

[!div class="tabbedCodeSnippets"]

   <WORKFLOW>
      <STATES>
        <STATE value="New">
          <FIELDS>
            <FIELD refname="Microsoft.VSTS.Common.ResolvedDate">
              <EMPTY />
            </FIELD>
            <FIELD refname="Microsoft.VSTS.Common.ResolvedBy">
              <EMPTY />
            </FIELD>
            <FIELD refname="Microsoft.VSTS.Common.ResolvedReason">
              <EMPTY />
            </FIELD>
            <FIELD refname="Microsoft.VSTS.Common.ClosedDate">
              <EMPTY />
            </FIELD>
            <FIELD refname="Microsoft.VSTS.Common.ClosedBy">
              <EMPTY />
            </FIELD>
            <FIELD refname="Microsoft.VSTS.Common.ActivatedDate">
              <EMPTY />
            </FIELD>
            <FIELD refname="Microsoft.VSTS.Common.ActivatedBy">
              <EMPTY />
            </FIELD>
          </FIELDS>
        </STATE>
        <STATE value="Active">
          <FIELDS>
            <FIELD refname="Microsoft.VSTS.Common.ResolvedDate">
              <EMPTY />
            </FIELD>
            <FIELD refname="Microsoft.VSTS.Common.ResolvedBy">
              <EMPTY />
            </FIELD>
            <FIELD refname="Microsoft.VSTS.Common.ResolvedReason">
              <EMPTY />
            </FIELD>
            <FIELD refname="Microsoft.VSTS.Common.ClosedDate">
              <EMPTY />
            </FIELD>
            <FIELD refname="Microsoft.VSTS.Common.ClosedBy">
              <EMPTY />
            </FIELD>
          </FIELDS>
        </STATE>
        <STATE value="Resolved">
          <FIELDS>
            <FIELD refname="Microsoft.VSTS.Common.ClosedDate">
              <EMPTY />
            </FIELD>
            <FIELD refname="Microsoft.VSTS.Common.ClosedBy">
              <EMPTY />
            </FIELD>
          </FIELDS>
        </STATE>
        <STATE value="Closed" />
      </STATES>

Activated By and Activated Date transition assignments

When the following transitions occur for a Bug work item, then the following assignments are made to the Activated By and Activated Date fields:

[!div class="tabbedCodeSnippets"]

<TRANSITION from="" to="New">
<TRANSITION from="New" to="Active">
<TRANSITION from="New" to="Resolved">
<TRANSITION from="New" to="Closed">
<TRANSITION from="Resolved" to="Active">
<TRANSITION from="Closed" to="Active">

[!div class="tabbedCodeSnippets"]

<FIELDS>
   <FIELD refname="Microsoft.VSTS.Common.ActivatedBy">
       <COPY from="currentuser" />
           <VALIDUSER />
           <REQUIRED />
    </FIELD>
    <FIELD refname="Microsoft.VSTS.Common.ActivatedDate">
        <SERVERDEFAULT from="clock" />
   </FIELD>
</FIELDS>

And when the following transitions occur for the Bug work item:

[!div class="tabbedCodeSnippets"]

<TRANSITION from="Active" to="New">
<TRANSITION from="Active" to="Closed">
<TRANSITION from="Resolved" to="Closed">

Then the Activated By and Activated Date fields are set to READONLY.

[!div class="tabbedCodeSnippets"]

<FIELD refname="Microsoft.VSTS.Common.ActivatedDate">
   <READONLY />
</FIELD>
<FIELD refname="Microsoft.VSTS.Common.ActivatedBy">
   <READONLY />
</FIELD>

::: moniker-end

[!INCLUDE activated-resolved-by-fields]

Related articles

[!INCLUDE temp]