Work item fields and attributes in Azure Boards

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Work item fields are used to track information. Fields are defined for an organization and shared across all projects defined for that organization. You can use one of two tools to review the fields defined for the organization. These tools are available for both Inherited and Hosted XML process models.

• Process>Fields web page
• Work Item Field Explorer

For a description of each field defined with a system process, see Work item field index.

Prerequisites

• To view the fields defined for an organization or collection, you must be a member of the Project Collection Valid Users application group or have the View instance-level information permission set to Allow for the organization or collection.

List or review fields

To list or review fields, you can use one of the following tools, depending on the process model—Inheritance, Hosted XML, or On-premises XML—you use. For an index of fields defined within the default processes, see Work item field index.

Tool	Inheritance	Hosted XML	On-premises XML
Web portal: List inherited and custom-defined fields	✔️	✔️1
Work item field explorer	✔️	✔️	✔️
witadmin listfields command line tool	✔️	✔️	✔️

Note

1. Only supported for default processes (Agile, CMMI, Scrum).

Field data types and names

Each work item type specifies the fields defined for the work items that reference that type. Each field is associated with a number of attributes, many of which are set by the system and cannot be changed.

Each field is defined by the following three attributes.

• Data type: Specifies the type of data that can be entered into the field, such as Boolean, Double, Integer, HTML, and String. For descriptions of each data type, see Query fields, operators, and macros.
• Friendly name: Specifies the name assigned to the field and that you select for a Field in a query clause. This name may differ from the name displayed on the work item form.
• Reference name: Specifies the name that you use when creating WIQL query or an improvised work item template, using REST API commands, or defining XML work item type definitions. Once defined, the reference name cannot be changed.

For a description of each field attribute and how you can list them, see Field attributes and List field attributes later in this article. For an overview of WITs and work items, see Track work with user stories, issues, bugs, features, and epics.

What is a field? How are field names used?

Each work item type is associated with 31 system fields and several more type-specific fields. You use work items to plan and track your project.

Each field supports tracking a piece of information about the work to perform. Values you assign to a field are stored in the work tracking data store which you can create queries to determine status and trends.

For descriptions and usage of each field defined for the core system processes, Agile, Basic, Scrum, and CMMI processes, see Work item field index.

Field names

A work item field name uniquely identifies each work item field. Make sure your field names fall within these guidelines:

• Field names must be unique within the account/project collection
• Field names must be 128 or fewer Unicode characters
• Field names can't contain any leading or trailing spaces, nor two or more consecutive spaces
• Field names must contain at least one alphabetic character
• Field names can't contain the following characters: .,;'`:~\/\*|?"&%$!+=()[]{}<>.

Because custom fields are defined for an organization or collection, you can't add a custom field to a process with the same field name that you add to another process.

For more information, see Naming restrictions and conventions.

System and predefined fields

All system defined fields have reference names that begin with System, for example, System.AreaPath, System.AssignedTo, and continue in that pattern.

Predefined fields defined by the default process begin with Microsoft.VSTS and then further differ based on their usage. Examples of predefined fields that are used in common, for scheduling purposes and integration with Office Project, for integration with Team Foundation Build, and integration with test case management (TCM) are as follows:

• Microsoft.VSTS.Common.Priority
• Microsoft.VSTS.Scheduling.DueDate
• Microsoft.VSTS.Build.FoundIn
• Microsoft.VSTS.TCM.Steps

For an overview of all system and predefined fields that are defined for the default processes/process templates, see Work item field index. For more information about specifying field names, see Naming restrictions.

Custom fields

Because custom fields are defined for an organization or project collection, you can't add a custom field to a process with the same field name that you add to another process.

When adding custom fields, note the following limits:

• A maximum of 64 fields can be defined for each WIT
• A maximum of 512 fields can be defined per process

The field data type determines the kind and size of data that you can store in the field. A field can have only one type defined within a project collection. This restriction encourages organizations to use common fields across projects and work item types.

When you add a custom field to an inherited process, Azure DevOps assigns a reference name prefixed with Custom and then the name of the field with spaces removed. For example, you add a field named DevOps Triage, the reference name is Custom.DevOpsTriage. No spaces are allowed within the reference name.

How can I determine the field data type?

You can view the data type of fields defined for your organization by opening the Process>Fields page.

Process>Fields web page

To review the list of fields defined for an organization or collection, open Organization settings>Process>Fields.

1. Choose the Azure DevOps logo to open Projects. Then choose Organization settings.

   

2. Then, choose Process.

   

   Note

   If you don't see Process, then you're working from TFS-2018 or earlier version. The Process page isn't supported. You must use the features supported for the On-premises XML process model.

3. Then, choose Fields.

   Fields listed correspond to all fields defined for the organization or collection. This includes all custom fields and those defined for system processes.

   

   Note

   If you don't see Fields, then your collection uses the On-premises XML process. The Fields page isn't supported for that process.

   For descriptions and usage of each field, as well as the Reference name for each field, you can look it up from the Work item field index. You can also get the Reference name of fields from the Work Item Types Field - List REST API.

Work Item Field Explorer

You can look up the assignments of field attributes using the Work Item Field Explorer tool.

To access the Work Item Field Explorer, you must install the Process Editor Tool. Based on the version of Visual Studio you have installed, get the Process Editor Tool from one of the following extensions.

• Visual Studio 2019 & 2022: As of now, there's no specific Process Template Editor extension available. But, you can still customize process templates using other tools such as any text editor or XML editor. You can also use the Azure DevOps web portal for certain customizations, especially for inherited processes.
• Visual Studio 2017: TFS Process Template Editor. You can also use this version of the Process Editor to modify the old-style work item forms. You can't use it to edit forms associated with the new web forms.
• Visual Studio 2015: TFS Power Tools.

Field attributes

There are many non-changeable and hidden attributes for each work item field. The following table describes each attribute. Attributes have different names based on if you get them through the Fields - Get REST API or view through the Work Item Field Explorer (WIFE) tool.

Attributes assigned to a field depend on the platform and version you use. For example, some attributes aren't support with the Inheritance process. To look up the reference name for a field, see Work item field index.

Attribute

Attribute type

Description

---

REST:
WIFE: AllowedValues

collection

Gets the collection of valid values for a field that contains picklist values. You can change this by specifying a picklist or global list (on-premises).
Can change?=Yes

REST: canSortBy
WIFE: CanSortBy

boolean

Indicates whether you can sort query results with this field.
Can change?=No

REST: description
WIFE: HelpText

string

Specifies a description for the field, which also defines the help text that appears when you hover over the field within the work item form.
Can change?=Yes

REST:
WIFE: ID

Integer

Specifies the internal ID of the field.
Can change?=No

REST:
WIFE: IsCloneable

boolean

Indicates whether the value defined for the field is copied when a user chooses to copy a work item. For example, Title, Tags, and Description fields are copied, but the ID and History fields aren't copied.
Can change?=No

REST:
WIFE: IsComputed

boolean

Indicates if the value set by this field is computed by the system (True) or not (False). Examples of computed fields are ones that are set by the system, such as the ID, Revised Date, Changed Date, and External Link Count.
Can change?=No

REST:
WIFE: IsCoreField

boolean

Indicates whether this field is specified for all work item types.
Can change?=No

REST:
WIFE: IsEditable

boolean

Indicates if users can modify this field (True) or not (False). Examples of non-editable fields are ones that are set by the system, such as the ID, Revision, Created By, and Changed By fields
Can change?=No

REST: isIdentity
WIFE: IsIdentity

boolean

Indicates whether this field is an Identity field. Identity fields are string fields used to store user identities.
Can change?=No

REST:
WIFE: IsIndexed¹

boolean

Indicates whether this field is indexed to support search.
Can change?=No

REST:
WIFE: IsLongText

boolean

Indicates that the field can contain more than 255 characters, such as fields assigned a data type of PlainText, HTML, or History.
Can change?=No

REST: isPicklist² WIFE:

boolean

Indicates whether the field is associated with a picklist. The value is set to True when a custom field is defined for Azure DevOps and Picklist (String) or Picklist (Integer) type is selected. The value is set to False for inherited fields that define picklists.
Can change?=No

REST: isPicklistSuggested² WIFE:

boolean

Indicates whether the field allows users to enter their own values for a picklist. The value is set to True when a custom field is defined for Azure DevOps, Picklist (String), or Picklist (Integer) type is selected, and the checkbox for Allow users to set their own values is checked.
Can change?=Yes

REST: isQueryable
WIFE: IsQueryable

boolean

Indicates if the field shows up within the set of fields you can add to filter a work item query (True), or not (False). Most fields are queryable.
Can change?=No

REST:
WIFE: IsReportable ³

boolean

Indicates if the reportable attribute is defined or set to anything other than None. This attribute can be changed for on-premises environments.
Can change?=Yes

REST:
WIFE: IsUsedInGlobalWorkflow

boolean

Indicates if the field is defined within a global workflow.
Can change?=No

REST:
WIFE: IsUserNameField

boolean

Indicates if the field is used to display an Identity field.
Can change?=No

REST: name
WIFE: Name

string

Friendly name assigned to the field. The friendly name can't be changed for Azure DevOps, but can be changed for on-premises using the witadmin changefield command.
Can change?=On-prem only

REST: picklistId
WIFE: HelpText

GUID

If the field is a picklist, the identifier of the associated picklist, otherwise null. A unique GUID value is assigned when a custom field is defined for Azure DevOps and Picklist (String) or Picklist (Integer) type is selected.
Can change?=No

REST:
WIFE: ProhibitedValues

collection

Gets the collection of prohibited values for a field that specifies such values. You can only define prohibited values for on-premises deployments.
Can change?=On-prem only

REST: readOnly
WIFE:

boolean

Indicates whether the field is set to read only. For Azure DevOps Services, only custom fields can be changed to be read-only. System fields cannot be modified.
Can change?=Yes

REST: referenceName
WIFE: ReferenceName

string

Specifies the reference name of a field.
Can change?=No

REST:
WIFE: ReportingAttributes³

Specifies Detail, Dimension, or Measure, depending on whether and how you want the field to be included in reports. Data from fields that have a value other than None for this attribute are exported to the data warehouse and can be included in SQL reports.
Can change?=On-prem only

REST:
WIFE: ReportingName³

string

Specifies the label for a field when data appears in SQL reports. If you don't specify a value, the field's friendly name is used.
Can change?=On-premises only

REST:
WIFE: ReportingReferenceName³

string

Specifies a different reference name to a field that is used when data is exported to the relational data warehouse. If you don't specify a value, the fields reference name is used.
Can change?=On-premises only

REST: supportedOperations
WIFE:

set

The set of query operators that are valid for use when referencing this field. For a quick reference of supported operations based on data type, see Query quick reference, Operators, and macros supported for each data type.
Can change?=No

REST:
WIFE: SupportsTextQuery

boolean

Indicates whether the field supports text queries such as Contains Words, Does Not Contains Words.
Can change?=No

REST:
WIFE: SystemType

string

Specifies the data type of the field, referencing the system name such as System.DateTime or System.String.
Can change?=No

REST: type
WIFE: FieldType

string

Specifies the data type of the field, such as Boolean, DateTime, Integer, String, and so on. For a complete list and descriptions, see Query fields, operators, and macros.
Can change?=No

REST: usage
WIFE: Usage

string

Specifies whether the field is intended for use with work items (WorkItem) or work item link (WorkItemLink) objects. The usage for most fields is WorkItem. For a complete list of usage values, see Get Fields, FieldUsage.
Can change?=No

Note

1. For on-premises deployments, you can enable indexing for a field to improve query response times when filtering on the field. For more information, see Indexed fields later in this article.
2. The isPicklist and isPicklistSuggested attributes are only assigned to custom fields defined for an inherited process. The Inherited process model is supported for Azure DevOps Server 2019 and later versions. For more information, see Inherited process model.
3. All reporting attributes are valid only for on-premises deployments whose projects have been configured to support SQL Server Reporting and SQL Server Analysis Services.

List field attributes

You can list the attributes assigned to a field by using the Fields - Get REST API. Enter your organization name for OrganizationName.

https://dev.azure.com/OrganizationName/_apis/wit/fields/FieldReferenceName

For example, here we list the attributes for the Iteration Path, specifying the reference name, System.IterationPath, for the fabrikam organization.

https://dev.azure.com/fabrikam/_apis/wit/fields/System.IterationPath

Returned data:

{
"name": "Iteration Path",
"referenceName": "System.IterationPath",
"description": "The iteration within which this bug will be fixed",
"type": "treePath",
"usage": "workItem",
"readOnly": false,
"canSortBy": true,
"isQueryable": true,
"supportedOperations": [
{
"referenceName": "SupportedOperations.Under",
"name": "Under"
},
{
"referenceName": "SupportedOperations.NotUnder",
"name": "Not Under"
},
{
"referenceName": "SupportedOperations.Equals",
"name": "="
},
{
"referenceName": "SupportedOperations.NotEquals",
"name": "<>"
},
{
"referenceName": "SupportedOperations.In",
"name": "In"
},
{
"name": "Not In"
}
],
"isIdentity": false,
"isPicklist": false,
"isPicklistSuggested": false,
"url": "https://dev.azure.com/mseng/_apis/wit/fields/System.IterationPath"
}

Add and modify fields

To add fields to a process, you add them to one or more work item types. For more information, see Customize an inheritance process.

Related articles

• Query quick reference
• Work item field index
• Add and manage fields for an inherited process
• Metadata reference for Azure Boards Analytics