| title | Resolve validation errors |
|---|---|
| titleSuffix | Azure DevOps Services |
| description | Fix errors reported upon importing a process to support customization of tracking work in Azure DevOps Services. |
| ms.service | azure-devops-boards |
| ms.custom | engagement-fy23, copilot-scenario-highlight |
| ms.assetid | 2407FB2B-FAE6-4BBB-99CB-B88904293A43 |
| ai-usage | ai-assisted |
| ms.topic | troubleshooting |
| ms.author | chcomley |
| author | chcomley |
| monikerRange | azure-devops |
| ms.date | 12/03/2025 |
[!INCLUDE version-eq-azure-devops]
Important
Import process supports the Hosted XML process model which allows you to manage customizations through updating the WIT definition of a process template. This feature is only available for organizations migrated to Azure DevOps Services using the Azure DevOps data import service.
If you use the Inheritance process model, you can customize your work tracking through the user interface by creating an inherited process. If you use the On-premises XML process model, you can customize a process template: Upload or download a process template and Customize a process template.
For more information, see Customize work tracking.
During process import, the process is validated to ensure the system works as expected for the custom process. You receive a list of error messages if the process fails validation.
If you received a validation error when you tried import process, resolve the error before retrying the import. Each error has a link to learn more about the specific validation failure and guidance on how to correct it. Apply the resolution fix provided for the message that you received, zip up the updated files, and retry the import operation.
If you're just starting your customization, review the validation rules provided.
[!INCLUDE process-prerequisites]
The following example prompt for Copilot Chat helps you troubleshoot process import validation errors and XML configuration issues. Copy and paste this prompt into Copilot Chat, replacing the placeholders with your specific information.
For the best AI assistance, include specific details like the error code (TF######), affected file names, work item type names, and field reference names mentioned in the validation error.
I'm getting this Azure DevOps process import error: [PASTE YOUR ERROR MESSAGE HERE]
Process import details:
- Error code: [ERROR CODE like TF402###]
- Affected file: [XML FILE NAME like Bug.xml, ProcessConfiguration.xml]
- Work item type: [WIT NAME if applicable]
- Field reference name: [FIELD REFNAME if applicable]
- Custom namespace: [YOUR CUSTOM NAMESPACE if applicable]
Can you help me troubleshoot this issue? Please provide step-by-step instructions to:
1. Identify the root cause of the validation error
2. Fix the XML configuration or process definition
3. Verify the changes resolve the validation issue
Context: This is for importing a custom process template to Azure DevOps Services using the Hosted XML process model. The error might be related to work item type definitions, field configurations, process configuration, categories, or XML schema violations.
Copilot is powered by AI, so surprises and mistakes are possible. For more information, see Copilot general use FAQs.
The process that you're importing doesn't include the named field in the process being updated, therefore it gets removed as part of the update operation.
- Add custom field to Bug.xml work item
<FIELD name="Foo" refname="MyCompany.CustomFields.Foo" type="String" reportable="dimension" />
- Import process
- Remove field from Bug.xml
- Import updated process
The system displays an information message about the field to be deleted.
TF402555: Field MyCompany.CustomFields.Foo will be deleted
TF402591: Field with reference name [refName] can't be renamed to '[name1]' from '[name2]' in existing processes [processName].
The process that you're importing contains a renamed field that uses the same refname in the current process.
You can't rename field names.
The process that you're updating doesn't include the named WIT that exists in the current process. As part of updating the existing process, the system deletes the named WIT from the current process.
- Create new work item type called "LSI"
<WORKITEMTYPE name="LSI" refname="My.LSI">
- Import process
- Remove the LSI work item type from the process
- Import updated process
The system displays an information message about the deletion.
TF402598: Work item type My.LSI will be deleted
The process contains a renamed WIT. The WIT is renamed in the existing process.
The process that you're updating contains a WIT that gets renamed from the name in the current process.
As part of updating the existing process, the system renames the WIT in the current process. All work items in existing projects that reference the process are also renamed.
- Create new work item type called "LSI"
<WORKITEMTYPE name="LSI" refname="My.LSI">
- Import process
- Rename the LSI work item type to Live Site Incident
<WORKITEMTYPE name="Live Site Incident" refname="My.LSI">
- Import updated process
The system displays an information message about the WIT to be renamed.
TF402601: Work item type My.LSI will be renamed to 'Live Site Incident' from 'LSI'
Malformed XML syntax can cause parsing file errors. Missing closing tags, missing quotes, missing open or close brackets (< or >) can cause a parsing file error.
From the error message, determine and correct the source of the malformed XML.
Each XML file in the process zip file must conform to the given schema. Schema violation errors are due to custom XML tags or attributes within the XML file. Read the error message to determine the source of schema violation and fix accordingly.
The schema definition for work item tracking defines all child elements within the FORM element as camel case and all other elements as all capitalized. If you encounter errors when validating your type definition files,
check the case structure of your elements. Also, the case structure of opening and closing tags must match according to the rules for XML syntax.
Custom XML tag:
<WORKITEMTYPE name="Bug" refname="My.Bug">
<FOO>Hello World</FOO>
...Extra attribute added to XML element:
<WORKITEMTYPE name="Bug" refname="My.Bug" foo="hello world">Correct the schema error in the named file.
The ProcessTemplate.xml is the root file that defines the entire process and all XML definition files that are imported to add or update a process. This file contains all of the plug-ins and task groups that are referenced when creating a project. Each task group references a subordinate XML file (often in a subfolder) where the specific tasks are defined. In general, you specify one task group for each plug-in.
The ProcessTemplate.xml definition file must conform to the syntax and rules.
Correct the process zip package to include the named file.
To specify a version, edit the ProcessTemplate.xml file.
ProcessTemplate.xml file specifies the same version GUID as for the Agile process, which is a locked process.
<ProcessTemplate>
<metadata>
<name>Fabrikam Agile</name>
<description>Use this template to support Fabrikam Agile planning methods.</description>
<version type="ADCC42AB-9882-485E-A3ED-7678F01F66BC" major="7" minor="36" />A different GUID is specified.
<ProcessTemplate>
<metadata>
<name>Fabrikam Agile</name>
<description>Use this template to support Fabrikam Agile planning methods.</description>
<version type="7710F7A4-1F19-4054-9FBC-D94A5935221E" major="7" minor="1" />All files listed within the ProcessTemplate.xml file and its supported plug-in files must be present within the process zip file.
Use a search tool to find all instances of filename=value within the set of process files and folders. Then, either update the plug-in to remove the missing named file, or add the named file to the process folder where it belongs.
<taskList filename="WorkItem Tracking\WorkItems.xml" />The WorkItemTracking plug-in specifies fileName="WorkItem Tracking\TypeDefinitions\Epic.xml,
however it isn't added to the WorkItem Tracking\TypeDefinitions folder.
<WORKITEMTYPE fileName="WorkItem Tracking\TypeDefinitions\Epic.xml" />Add the Epic.xml file to the WorkItem Tracking\TypeDefinitions folder.
VS412454: Plug-in [pluginName] contains several taskList {1}, {2}. Only one taskList per plugin is allowed.
Correct the ProcessTemplate.xml file for the named plug-in to reduce the number of tasklist elements defined.
The WorkItemTracking plug-in contains two tasklist statements.
<group id="WorkItemTracking" description="Workitem definitions uploading." completionMessage="Work item tracking tasks completed.">
<dependencies>
<dependency groupId="Classification" />
<dependency groupId="Groups" />
</dependencies>
<taskList filename="WorkItem Tracking\WorkItems.xml" />
<taskList filename="WorkItem Tracking\FabrikamWorkItems.xml" />
</group> <group id="WorkItemTracking" description="Workitem definitions uploading." completionMessage="Work item tracking tasks completed.">
<dependencies>
<dependency groupId="Classification" />
<dependency groupId="Groups" />
</dependencies>
<taskList filename="WorkItem Tracking\FabrikamWorkItems.xml" />
</group>The WorkItems.xml file contains two CATEGORIES statements.
<task id="Categories" name="Categories definitions" plugin="Microsoft.ProjectCreationWizard.WorkItemTracking" completionMessage="Work item type categories created">
<dependencies>
<dependency taskId="WITs" />
</dependencies>
<taskXml>
<CATEGORIES fileName="WorkItem Tracking\Categories.xml" />
<CATEGORIES fileName="WorkItem Tracking\Custom_Categories.xml" />
</taskXml>
</task>The WorkItems.xml file is updated to contain only one CATEGORIES statement.
<task id="Categories" name="Categories definitions" plugin="Microsoft.ProjectCreationWizard.WorkItemTracking" completionMessage="Work item type categories created">
<dependencies>
<dependency taskId="WITs" />
</dependencies>
<taskXml>
<CATEGORIES fileName="WorkItem Tracking\Custom_Categories.xml" />
</taskXml>
</task>The WorkItems.xml file contains duplicate ProjectConfiguration statements.
<taskXml>
<PROCESSCONFIGURATION>
<ProjectConfiguration fileName="WorkItem Tracking\Process\ProcessConfiguration.xml"/>
</PROCESSCONFIGURATION>
</taskXml>
<taskXml>
<PROCESSCONFIGURATION>
<ProjectConfiguration fileName="WorkItem Tracking\Process\ProcessConfiguration.xml"/>
</PROCESSCONFIGURATION>
</taskXml>The WorkItems.xml file is updated to contain only one ProjectConfiguration statement.
<taskXml>
<PROCESSCONFIGURATION>
<ProjectConfiguration fileName="WorkItem Tracking\Process\ProcessConfiguration.xml"/>
</PROCESSCONFIGURATION>
</taskXml>The WorkItems.xml file specifies the ProcessConfiguration file to upload. Either the file isn't specified, contains an out-of-date specification, the specified file is missing from the template, or the folder/file name isn't correct.
The configuration specified is out-of-date and specifies two files that aren't contained in the Process folder.
<taskXml>
<PROCESSCONFIGURATION>
<CommonConfiguration fileName="WorkItem Tracking\Process\CommonConfiguration.xml"/>
<AgileConfiguration fileName="WorkItem Tracking\Process\AgileConfiguration.xml"/>
</PROCESSCONFIGURATION>
</taskXml>The WorkItems.xml file is updated to contain the correct configuration ProjectConfiguration statement.
<taskXml>
<PROCESSCONFIGURATION>
<ProjectConfiguration fileName="WorkItem Tracking\Process\ProcessConfiguration.xml"/>
</PROCESSCONFIGURATION>
</taskXml>TF402577: Field [refName] specifies friendly name [friendlyName] which is already in use by fields [refName] in processes [processNames].
Friendly names must be unique across all field definitions for all WIT definitions specified for all processes imported to Azure DevOps Services.
The named processes contain WITs that define a field that uses the friendly name.
Modify the WIT definition in your process zip file that contains [refName] and specify a different friendly name or make it match an existing field in use.
The UserStory WIT definition contains FIELD element for Fabrikam.Product.Family with friendly name Product.
<FIELD name="Product" refname="Fabrikam.Product.Family" type="String" reportable="dimension">
<HELPTEXT>Enter the name of the product family for this story or feature.</HELPTEXT>
</FIELD>However, in an existing process, Fabrikam.Product.Versions uses the friendly name Product.
<FIELD name="Product" refname="Fabrikam.Product.Versions" type="String" reportable="dimension">
<HELPTEXT>Enter the name of the product version for this story or feature.</HELPTEXT>
</FIELD>Update the UserStory WIT definition to match the existing field.
<FIELD name="Product" refname="Fabrikam.Product.Versions" type="String" reportable="dimension">
<HELPTEXT>Enter the name of the product version for this story or feature.</HELPTEXT>
</FIELD>You must specify the Microsoft.ProjectCreationWizard.WorkItemTracking plug-in in the metadata section of the ProcessTemplate.xml file:
The Microsoft.ProjectCreationWizard.WorkItemTracking plug-in is missing from the plugins section of the ProcessTemplate.xml file.
<plugins>
<plugin name="Microsoft.ProjectCreationWizard.Classification" wizardPage="false" />
<plugin name="Microsoft.ProjectCreationWizard.Reporting" wizardPage="false" />
<plugin name="Microsoft.ProjectCreationWizard.Portal" wizardPage="true" />
<plugin name="Microsoft.ProjectCreationWizard.Groups" wizardPage="false" />
<plugin name="Microsoft.ProjectCreationWizard.VersionControl" wizardPage="true" />
<plugin name="Microsoft.ProjectCreationWizard.TestManagement" wizardPage="false" />
<plugin name="Microsoft.ProjectCreationWizard.Build" wizardPage="false" />
<plugin name="Microsoft.ProjectCreationWizard.Lab" wizardPage="false" />
</plugins> <plugins>
<plugin name="Microsoft.ProjectCreationWizard.Classification" wizardPage="false" />
<plugin name="Microsoft.ProjectCreationWizard.Reporting" wizardPage="false" />
<plugin name="Microsoft.ProjectCreationWizard.Portal" wizardPage="true" />
<plugin name="Microsoft.ProjectCreationWizard.Groups" wizardPage="false" />
<plugin name="Microsoft.ProjectCreationWizard.WorkItemTracking" wizardPage="false" />
<plugin name="Microsoft.ProjectCreationWizard.VersionControl" wizardPage="true" />
<plugin name="Microsoft.ProjectCreationWizard.TestManagement" wizardPage="false" />
<plugin name="Microsoft.ProjectCreationWizard.Build" wizardPage="false" />
<plugin name="Microsoft.ProjectCreationWizard.Lab" wizardPage="false" />
</plugins>The Categories.xml definition file must conform to the syntax and rules.
All categories that are referenced in the ProcessConfiguration.xml file must be defined in the Categories.xml file. In addition, the system requires that the Categories.xml file contain definitions for the following categories:
- Bug Category
- Code Review Request Category
- Code Review Response Category
- Feedback Request Category
- Feedback Response Category
- Hidden Types Category
- Requirement Category
- Shared Step Category
- Shared Parameter Category
- Task Category
- Test Case Category
- Test Plan Category
- Test Suite Category
Update your Categories.xml file to define the missing [name] category.
ProcessConfiguration references the Epic Category, however it's missing from the Categories.xml definition file.
Epic Category is added to the Categories file.
<CATEGORY name="Epic Category" refname="Microsoft.EpicCategory">
<DEFAULTWORKITEMTYPE name="Epic" />
</CATEGORY>TF402553: Element [name] references category [categoryName] which isn't defined in the categories file.
Update your Categories.xml file to define the missing [categoryName] category.
Review your Categories.xml file for all CATEGORY element statements and determine which ones you can delete so as not exceed the allowed limit.
Then, review your ProcessConfiguration.xml file to replace values that reference deleted categories.
Categories must reference WITs that are defined in the /WorkItem Tracking/TypeDefinitions folder and listed as a task for upload in the WorkItems.xml plug-in file.
Review your Categories.xml file for references to a WIT that isn't included in the /WorkItem Tracking/TypeDefinitions folder.
The name of the WIT referenced for Microsoft.EpicCategory is misspelled.
<CATEGORY name="Epic Category" refname="Microsoft.EpicCategory">
<DEFAULTWORKITEMTYPE name="EpicABC" />
</CATEGORY> <CATEGORY name="Epic Category" refname="Microsoft.EpicCategory">
<DEFAULTWORKITEMTYPE name="Epic" />
</CATEGORY>TF402597: Custom category [categoryName] isn't supported because ProcessConfiguration doesn't reference it.
You can only specify custom categories that you use to configure an Agile tool feature in the ProcessConfiguration.
Review your ProcessConfiguration.xml file and determine if you missed adding support for a category. Otherwise, remove [categoryName] from the Categories.xml file.
ProcessConfiguration doesn't reference Microsoft.EpicCategory, although defined in the Categories.xml definition file.
Add PortfolioBacklog to ProcessConfiguration to reference Microsoft.EpicCategory.
<PortfolioBacklog category="Microsoft.EpicCategory" pluralName="Epics" singularName="Epic" workItemCountLimit="1000">
<States>
<State value="New" type="Proposed" />
<State value="Active" type="InProgress" />
<State value="Resolved" type="InProgress" />
<State value="Closed" type="Complete" />
</States>
<Columns>
<Column refname="System.WorkItemType" width="100" />
<Column refname="System.Title" width="400" />
<Column refname="System.State" width="100" />
<Column refname="Microsoft.AzureDevOps.Scheduling.Effort" width="50" />
<Column refname="Microsoft.AzureDevOps.Common.BusinessValue" width="50" />
<Column refname="Microsoft.AzureDevOps.CMMI.RequirementType" width="100" />
<Column refname="System.Tags" width="200" />
</Columns>
<AddPanel>
<Fields>
<Field refname="System.Title" />
</Fields>
</AddPanel>
</PortfolioBacklog>Reference articles:
The Classification.xml definition file must conform to the syntax and rules.
Classification.xml file contains a second property name="MSPROJ" statement under the properties container element.
<properties>
<property name="MSPROJ" value="Classification\FileMapping.xml" isFile="true" />
<property name="MSPROJ" value="Classification\Fabrikam_FileMapping.xml" isFile="true" />
<property name="Process Template" value="Fabrikam Agile"/>
</properties>Remove the duplicate statement.
<properties>
<property name="MSPROJ" value="Classification\Fabrikam_FileMapping.xml" isFile="true" />
<property name="Process Template" value="Fabrikam Agile"/>
</properties>The file specified in the Classification.xml file isn't present in the specified path or the path is misspelled.
The Classification folder path is misspelled.
<properties>
<property name="MSPROJ" value="Classification\Fabrikam_FileMapping.xml" isFile="true" />
<property name="Process Template" value="Agile"/>
</properties> <properties>
<property name="MSPROJ" value="Classification\Fabrikam_FileMapping.xml" isFile="true" />
<property name="Process Template" value="Fabrikam Agile"/>
</properties>TF402513: Name [pathName] in the Classification plug-in doesn't conform to TreePath naming restrictions.
Review the Node elements you specified and change the names to conform to supporting naming conventions.
Reference: Add and modify area and iteration paths.
The Path names include the # character which isn't allowed.
<Node StructureType="ProjectLifecycle" Name="Iteration" xmlns="">
<Children>
<Node StructureType="ProjectLifecycle" Name="Sprint #1" />
<Node StructureType="ProjectLifecycle" Name="Sprint #2" />
<Node StructureType="ProjectLifecycle" Name="Sprint #3" />
</Children>
</Node>The Path names are corrected.
<Node StructureType="ProjectLifecycle" Name="Iteration" xmlns="">
<Children>
<Node StructureType="ProjectLifecycle" Name="Sprint 1" />
<Node StructureType="ProjectLifecycle" Name="Sprint 2" />
<Node StructureType="ProjectLifecycle" Name="Sprint 3" />
</Children>
</Node>The StructureType attribute only allows the following values: ProjectModelHierarchy and ProjectLifecycle.
Review the Node elements that you specified and remove any unsupported attributes.
ProjectLifecycle is misspelled.
<Node StructureType="ProjectLifecycle" Name="Iteration" xmlns="">
<Children>
<Node StructureType="ProjectLifecycle" Name="Sprint 1" />
<Node StructureType="ProjectLifecycle" Name="Sprint 2" />
<Node StructureType="ProjectLifecycle" Name="Sprint 3" />
</Children>
</Node>Misspelled name is corrected.
<Node StructureType="ProjectLifecycle" Name="Iteration" xmlns="">
<Children>
<Node StructureType="ProjectLifecycle" Name="Sprint 1" />
<Node StructureType="ProjectLifecycle" Name="Sprint 2" />
<Node StructureType="ProjectLifecycle" Name="Sprint 3" />
</Children>
</Node>The property element only allows the following attributes: name , value , and isFile.
Review the property elements you specified and remove any unsupported attributes.
The value attribute is misspelled.
<properties>
<property name="MSPROJ" value="Classification\Fabrikam_FileMapping.xml" isFile="true" />
<property name="Process Template" value="Agile" />
</properties>Misspelled attribute is corrected.
<properties>
<property name="MSPROJ" value="Classification\Fabrikam_FileMapping.xml" isFile="true" />
<property name="Process Template" value="Fabrikam Agile"/>
</properties>TF402516: The Classification plug-in contains more than two root level Nodes, which isn't supported.
Review the Node elements you specified and remove extra root level nodes.
Classification.xml file contains a second Node StructureType="ProjectLifecycle" statement under the Nodes container element.
<Nodes>
<Node StructureType="ProjectLifecycle" Name="Iteration" xmlns="">
<Children>
<Node StructureType="ProjectLifecycle" Name="Sprint 1" />
<Node StructureType="ProjectLifecycle" Name="Sprint 2" />
<Node StructureType="ProjectLifecycle" Name="Sprint 3" />
</Children>
</Node>
<Node StructureType="ProjectLifecycle" Name="Iteration" xmlns="">
<Node StructureType="ProjectModelHierarchy" Name="Area" xmlns="" />
</Nodes>Remove the second statement.
<Nodes>
<Node StructureType="ProjectLifecycle" Name="Iteration" xmlns="">
<Children>
<Node StructureType="ProjectLifecycle" Name="Sprint 1" />
<Node StructureType="ProjectLifecycle" Name="Sprint 2" />
<Node StructureType="ProjectLifecycle" Name="Sprint 3" />
</Children>
</Node>
<Node StructureType="ProjectModelHierarchy" Name="Area" xmlns="" />
</Nodes>TF402523: Area or Iteration path '[pathName]' in the GroupsandPermissions plug-is missing from the Classification plug-in.
Add the missing [pathName] to the Classification.xml file or remove it from the GroupsandPermissions.xml file.
Classification.xml file specifies sprints, not iterations.
GroupsandPermissions.xml teamSettings specifies Iterations.
<teamSettings areaPath="Area">
<iterationPaths backlogPath="Iteration">
<iterationPath path="Iteration 1" />
<iterationPath path="Iteration 2" />
<iterationPath path="Iteration 3" />
</iterationPaths>
</teamSettings>However, the Classification.xml specifies sprints.
<Node StructureType="ProjectLifecycle" Name="Iteration" xmlns="">
<Children>
<Node StructureType="ProjectLifecycle" Name="Sprint 1" />
<Node StructureType="ProjectLifecycle" Name="Sprint 2" />
<Node StructureType="ProjectLifecycle" Name="Sprint 3" />
</Children>
</Node>Update GroupsandPermissions.xml to use sprints.
<teamSettings areaPath="Area">
<iterationPaths backlogPath="Iteration">
<iterationPath path="Sprint 1" />
<iterationPath path="Sprint 2" />
<iterationPath path="Sprint 3" />
</iterationPaths>
</teamSettings>Note
Custom link types aren't supported in the current import process.
Review your WorkItems.xml plug-in file for all LINKTYPE element statements.
Remove statements associated with custom link types so as not exceed the allowed limit.
And then, remove the corresponding link type definition file from the LinkTypes folder.
Also, remove any references to the custom link types that you added to a WIT definition within a LinksControlOptions section under the FORM section.
Review your WorkItems.xml plug-in file for all LINKTYPE element statements. Remove any statements that specify a custom link type.
And then, remove the corresponding link type definition file from the LinkTypes folder.
The following LINKTYPE element statements within the WorkItems.xml plug-in file are valid:
<LINKTYPES>
<LINKTYPE fileName="WorkItem Tracking\LinkTypes\Affects.xml" />
<LINKTYPE fileName="WorkItem Tracking\LinkTypes\SharedStep.xml" />
<LINKTYPE fileName="WorkItem Tracking\LinkTypes\TestedBy.xml" />
<LINKTYPE fileName="WorkItem Tracking\LinkTypes\SharedParameterLink.xml" />
</LINKTYPES>Note
Global lists aren't supported in the current import process feature.
One or more WITs defined in the custom process template contain a GLOBALLIST element.
Search through your WIT definition files and replace any GLOBALLIST elements with ALLOWEDVALUES or SUGGESTEDVALUES elements.
The named GLOBALLIST element contains more items than allowed. Either reduce the number of list items contained in the GLOBALLIST element,
or segment the global list into two or more elements so that neither list exceeds the maximum number of allowed items.
The ProcessConfiguration.xml definition file must conform to the syntax and rules described in ProcessConfiguration XML element reference.
TF402543: Element [elementName] requires that you map exactly one workflow state to metastate [metastateName].
Update the States section within the named element in the ProcessConfiguration.xml file to provide the missing metastate mapping or remove extra mappings.
ProcessConfiguration.xml RequirementBacklog element is missing a metastate mapping for type="Proposed".
<RequirementBacklog category="Microsoft.RequirementCategory" pluralName="Backlog items" singularName="Backlog item">
<States>
<State value="Committed" type="InProgress" />
<State value="Done" type="Complete" />
</States>
. . .
</RequirementBacklog >Missing metastate mappings are added.
<RequirementBacklog category="Microsoft.RequirementCategory" pluralName="Backlog items" singularName="Backlog item">
<States>
<State value="New" type="Proposed" />
<State value="Committed" type="InProgress" />
<State value="Done" type="Complete" />
</States>
. . .
</RequirementBacklog >TF402547: Element [elementName] requires that for work item type [witName] you map at least one state to metastate [metastateName].
Review the WORKFLOW states defined for the named WIT and then update the States section within the
named element in the ProcessConfiguration.xml file to provide the missing metastate mapping for the named WIT.
TF402548: Element [elementName] requires that you map at least one state to metastate [metastateName].
To provide the missing metastate mapping, update the States section within the named element in the ProcessConfiguration.xml file.
ProcessConfiguration.xml RequirementBacklog element is missing a metastate mapping for type="InProgress".
<RequirementBacklog category="Microsoft.RequirementCategory" pluralName="Backlog items" singularName="Backlog item">
<States>
<State value="New" type="Proposed" />
<State value="Done" type="Complete" />
</States>
. . .
</RequirementBacklog >Missing metastate mappings are added.
<RequirementBacklog category="Microsoft.RequirementCategory" pluralName="Backlog items" singularName="Backlog item">
<States>
<State value="New" type="Proposed" />
<State value="Committed" type="InProgress" />
<State value="Done" type="Complete" />
</States>
. . .
</RequirementBacklog >TF402550: Element [elementName] includes more than one metastate mapping for workflow state [stateName].
Metastate value can't be mapped to more than one workflow state.
ProcessConfiguration.xml RequirementBacklog element contains two metastate mappings for value="Active".
<RequirementBacklog category="Microsoft.RequirementCategory" pluralName="Stories" singularName="Story">
<States>
<State value="Active" type="Proposed" />
<State value="Active" type="InProgress" />
<State value="Resolved" type="InProgress" />
<State value="Closed" type="Complete" />
</States>
. . .
</RequirementBacklog >Metastate mappings are corrected.
<RequirementBacklog category="Microsoft.RequirementCategory" pluralName="Stories" singularName="Story">
<States>
<State value="New" type="Proposed" />
<State value="Active" type="InProgress" />
<State value="Resolved" type="InProgress" />
<State value="Closed" type="Complete" />
</States>
. . .
</RequirementBacklog >TF402551: Work item type [witName] doesn't define workflow state [stateName], which is required because ProcessConfiguration maps it to a metastate for element [elementName].
To add the missing STATE and TRANSITION elements, either correct the ProcessConfiguration.xml file or the WORKFLOW section of the named WIT.
The ProcessConfiguration.xml RequirementBacklog element specifies value="Committed", however UserStory.xml doesn't define Committed as a State.
<RequirementBacklog category="Microsoft.RequirementCategory" pluralName="Stories" singularName="Story">
<States>
<State value="New" type="Proposed" />
<State value="Committed" type="InProgress" />
<State value="Active" type="InProgress" />
<State value="Resolved" type="InProgress" />
<State value="Closed" type="Complete" />
</States>
. . .
</RequirementBacklog >Removed the State element for Committed.
<RequirementBacklog category="Microsoft.RequirementCategory" pluralName="Stories" singularName="Story">
<States>
<State value="New" type="Proposed" />
<State value="Active" type="InProgress" />
<State value="Resolved" type="InProgress" />
<State value="Closed" type="Complete" />
</States>
. . .
</RequirementBacklog >TF402552: Element [elementName] requires that for work item type [witName] you map exactly one state to metastate [metastateName] for the following states: [stateNames].
Review the STATES section in the ProcessConfiguration.xml file for the named element and ensure that each sate listed in the error message is present and mapped to a metastate.
ProcessConfiguration.xml RequirementBacklog element is missing the state New which exists on the User Story work item type. It should be in the STATES list mapped to type=Proposed".
<RequirementBacklog category="Microsoft.RequirementCategory" pluralName="Stories" singularName="Story">
<States>
<State value="Active" type="InProgress" />
<State value="Resolved" type="InProgress" />
<State value="Closed" type="Complete" />
</States>
. . .
</RequirementBacklog >Metastate mapping is corrected.
<RequirementBacklog category="Microsoft.RequirementCategory" pluralName="Stories" singularName="Story">
<States>
<State value="New" type="Proposed" />
<State value="Active" type="InProgress" />
<State value="Resolved" type="InProgress" />
<State value="Closed" type="Complete" />
</States>
. . .
</RequirementBacklog >Review the STATES section in the ProcessConfiguration.xml file for the named element and remove or correct the named metastate.
ProcessConfiguration.xml RequirementBacklog element contains a misspelled metastate mapping for type=Proposed".
<RequirementBacklog category="Microsoft.RequirementCategory" pluralName="Stories" singularName="Story">
<States>
<State value="New" type="Proposed" />
<State value="Active" type="InProgress" />
<State value="Resolved" type="InProgress" />
<State value="Closed" type="Complete" />
</States>
. . .
</RequirementBacklog >Metastate mapping is corrected.
<RequirementBacklog category="Microsoft.RequirementCategory" pluralName="Stories" singularName="Story">
<States>
<State value="New" type="Proposed" />
<State value="Active" type="InProgress" />
<State value="Resolved" type="InProgress" />
<State value="Closed" type="Complete" />
</States>
. . .
</RequirementBacklog >Edit the ProcessConfiguration.xml file to add the missing named element.
Review ProcessConfiguration XML element reference for required elements.
A file specified in a plug-in file for upload is missing from the zip file. Review all files specified for upload and make sure they're included in the process zip file.
Review ProcessConfiguration XML element reference for required elements.
Edit the ProcessConfiguration.xml file to add the missing named TypeField element.
Review ProcessConfiguration XML element reference for required TypeField elements.
The Scrum process specifies the following TypeField elements. If any of these elements are missing, you receive error TF402574.
<TypeFields>
<TypeField refname="System.AreaPath" type="Team" />
<TypeField refname="Microsoft.AzureDevOps.Scheduling.RemainingWork" type="RemainingWork" format="format h" />
<TypeField refname="Microsoft.AzureDevOps.Common.BacklogPriority" type="Order" />
<TypeField refname="Microsoft.AzureDevOps.Scheduling.Effort" type="Effort" />
<TypeField refname="Microsoft.AzureDevOps.Common.Activity" type="Activity" />
<TypeField refname="Microsoft.AzureDevOps.Feedback.ApplicationStartInformation" type="ApplicationStartInformation" />
<TypeField refname="Microsoft.AzureDevOps.Feedback.ApplicationLaunchInstructions" type="ApplicationLaunchInstructions" />
<TypeField refname="Microsoft.AzureDevOps.Feedback.ApplicationType" type="ApplicationType">
<TypeFieldValues>
<TypeFieldValue value="Web application" type="WebApp" />
<TypeFieldValue value="Remote machine" type="RemoteMachine" />
<TypeFieldValue value="Client application" type="ClientApp" />
</TypeFieldValues>
</TypeField>
</TypeFields>TF402588: Several portfolio backlogs [backlogNames] have defined [backlogName] as their parent. A parent backlog might have only one child backlog.
Only one child portfolio backlog can map to a single parent backlog.
Edit ProcessConfiguration to correct the parent-child backlog specifications.
<PortfolioBacklog category="Microsoft.EpicCategory" parent="Microsoft.InitiativeCategory" pluralName="Epics" singularName="Epic">
...
</PortfolioBacklog>
<PortfolioBacklog category="Microsoft.FeatureCategory" parent="Microsoft.InitiativeCategory" pluralName="Features" singularName="Feature">
...
</PortfolioBacklog>To point to the Epic backlog, change the parent on the Feature backlog.
<PortfolioBacklog category="Microsoft.EpicCategory" parent="Microsoft.InitiativeCategory" pluralName="Epics" singularName="Epic">
...
</PortfolioBacklog>
<PortfolioBacklog category="Microsoft.FeatureCategory" parent="Microsoft.EpicCategory" pluralName="Features" singularName="Feature">
...
</PortfolioBacklog>TF402589: Portfolio backlog [backlogName] references undefined parent portfolio backlog [backlogName].
The ProcessConfiguration.xml definition contains a parent value that references an undefined portfolio backlog.
<PortfolioBacklog category="Microsoft.FeatureCategory" parent="Microsoft.EpicCategory" pluralName="Features" singularName="Feature">Add the Epic PortfolioBacklog to the ProcessConfiguration.xml file.
<PortfolioBacklog category="Microsoft.EpicCategory" pluralName="Epics" singularName="Epic">
<States>
<State value="New" type="Proposed" />
<State value="Active" type="InProgress" />
<State value="Resolved" type="InProgress" />
<State value="Closed" type="Complete" />
</States>
<Columns>
<Column refname="System.WorkItemType" width="100" />
<Column refname="System.Title" width="400" />
<Column refname="System.State" width="100" />
<Column refname="Microsoft.AzureDevOps.Common.BusinessValue" width="50" />
<Column refname="Microsoft.AzureDevOps.CMMI.RequirementType" width="100" />
<Column refname="System.Tags" width="200" />
</Columns>
</PortfolioBacklog>Only one portfolio backlog, the top backlog, might be unparented. All other backlogs must include a parent="Microsoft.FooCategory" attribute and value.
<PortfolioBacklog category="Microsoft.FeatureCategory" parent="Microsoft.EpicCategory" pluralName="Features" singularName="Feature">Edit the ProcessConfiguration.xml file to remove the extra PortfolioBacklog elements from the PortfolioBacklogs section.
Review ProcessConfiguration XML element reference for more information.
This error occurs when the BugWorkItems section is misconfigured.
Each state defined for a work item type included in the Microsoft.BugCategory must exist in the set of State values defined in the BugWorkItems section. For example, if the following states are defined for work item types defined for Bug work item type—New, Approved, Committed, Done—then the BugWorkItems section should be configured as follows:
<BugWorkItems category="Microsoft.BugCategory" pluralName="Bugs" singularName="Bug">
<States>
<States>
<State value="New" type="Proposed" />
<State value="Approved" type="Proposed" />
<State value="Committed" type="InProgress" />
<State value="Done" type="Complete" />
</States>
</BugWorkItems>For more information, see ProcessConfiguration XML element reference.
TF400507: Each work item type must support an initial state value that matches one of the states defined in: BugWorkItems.
This error occurs when a work item type included in the Microsoft.BugCategory specifies an initial state that isn't included in the BugWorkItems section of the ProcessConfiguration XML file. Either fix the XML definition workflow states for the named work item types, or update the BugWorkItems section to include the missing state.
For more information, see ProcessConfiguration XML element reference.
This error stems from old templates, before the Project Process Settings existed. Try to add the ProcessConfiguration XML file to the process template.
You defined more WITs that are allowed in the process. Review your WorkItems.xml file and reduce the number of WORKITEMTYPE statements it contains and remove the associated WIT definition files from the process.
Work item types (Bug, User Story, Task, etc.) require the refname attribute. The refname value must be unique and can't contain any reserved namespaces.
The namespaces-System.XXX and Microsoft.AzureDevOps.XXX-are reserved by Azure DevOps.
<WORKITEMTYPE name="Bug"><WORKITEMTYPE name="Bug" refname="MyCompany.Bug">TF402599: The work item type refname [refName] isn't valid as it uses a disallowed namespace [namespace].
Reference names of custom fields and WITs can't use reserved namespaces: System.XXX and Microsoft.AzureDevOps.XXX.
Edit the refname attribute of the named WIT.
<FIELD name="Custom Field" refname="Microsoft.AzureDevOps.CustomField" type="String" /><FIELD name="Custom Field" refname="*CustomNamespace.CustomField*" type="String" />TF402600: The work item type reference name [refName] isn't valid. Work item type reference names must contain only letters, no spaces, and at least one period (.)
WIT reference names must adhere to established naming conventions: only letters, no spaces, and at least one period (.)
Edit the refname attribute of the named WIT to meet naming requirements.
<WORKITEMTYPE name="Bug" refname="MyCompanyBug32"><WORKITEMTYPE name="Bug" refname="MyCompany.Bug">Edit your WIT definitions to remove the named rule.
The following rules are not supported for import to Azure DevOps:
MATCH, CANNOTLOSEVALUE, PROHIBITEDVALUES, and NOTSAMEAS.
Edit your WIT definitions for the named field and remove any nonallowed rules. Review both the FIELDS and WORKFLOW sections.
Most system fields don't allow specifying rules.
| Name | Allowed rules |
|---|---|
| System.Title | REQUIRED, DEFAULT |
| System.Description | REQUIRED, DEFAULT |
| System.AssignedTo | REQUIRED, DEFAULT, ALLOWEXISTINGVALUE, VALIDUSER |
| System.ChangedBy | REQUIRED, DEFAULT, ALLOWEXISTINGVALUE, VALIDUSER |
TF402540: Work item type [witName] isn't valid because it specifies global list [GLOBALLIST]. Global lists aren't supported.
Global lists aren't supported in Azure DevOps.
Replace all instances of GLOBALLIST elements with
ALLOWEDVALUES and LISTITEM elements in all WIT definition files.
<FIELD name="CustomField" refname="MyCompany.CustomField" type="String">
<ALLOWEDVALUES>
<GLOBALLIST name="Disciplines" />
</ALLOWEDVALUES>
</FIELD><FIELD name="CustomField" refname="MyCompany.CustomField" type="String">
<ALLOWEDVALUES>
<LISTITEM value="Architecture" />
<LISTITEM value="Requirements" />
<LISTITEM value="Development" />
<LISTITEM value="Release Management" />
<LISTITEM value="Project Management" />
<LISTITEM value="Test" />
</ALLOWEDVALUES>
</FIELD>TF402541: Work item type [witName] isn't valid because it references global list [globalListName]. Global lists aren't supported.
Global lists aren't supported in Azure DevOps. Replace all instances of GLOBALLIST elements with
ALLOWEDVALUES and LISTITEM elements in all WIT definition files.
<FIELD name="CustomField" refname="MyCompany.CustomField" type="String">
<ALLOWEDVALUES>
<GLOBALLIST name="Disciplines" />
</ALLOWEDVALUES>
</FIELD><FIELD name="CustomField" refname="MyCompany.CustomField" type="String">
<ALLOWEDVALUES>
<LISTITEM value="Architecture" />
<LISTITEM value="Requirements" />
<LISTITEM value="Development" />
<LISTITEM value="Release Management" />
<LISTITEM value="Project Management" />
<LISTITEM value="Test" />
</ALLOWEDVALUES>
</FIELD>TF402542: The custom field refname [refName] isn't valid as it uses disallowed namespace [namespace].
The namespaces-System.XXX and Microsoft.AzureDevOps.XXX-are reserved in Azure DevOps. Reference names of custom fields and types can't use these namespaces.
To fix this error, rename the refname attribute for the named field in the WIT definition files where it appears.
<FIELD name="CustomField" refname="System.CustomField" type="String" />
- OR -
<FIELD name="CustomField" refname="Microsoft.AzureDevOps.CustomField" type="String" /><FIELD name="CustomField" refname="MyCompany.CustomField" type="String" />TF402544: Field [refName], defined in work item type [witName], requires an ALLOWEDVALUES rule that contains values to support element [elementName] specified in ProcessConfiguration.
Edit the named field in the named WIT to provide the missing ALLOWEDVALUES rule, referencing the named element for more details.
The ProcessConfiguration.xml file element, TypeField refname="Microsoft.AzureDevOps.Common.Activity" type="Activity",
requires a pick list is defined for the Microsoft.AzureDevOps.Common.Activity field in all WITs that belong to the Task Category.
<TypeField refname="Microsoft.AzureDevOps.Common.Activity" type="Activity" />If you added bugs to the Task Category, ensure that the Bug.xml file contains the named field and specifies the same pick list as is defined for it in the Task.xml file.
Bug.xml has the field defined, but not the pick list.
<FIELD name="Activity" refname="Microsoft.AzureDevOps.Common.Activity" type="String" reportable="dimension">
<HELPTEXT>Type of work involved</HELPTEXT>
</FIELD> Corrected Bug.xml
<FIELD name="Activity" refname="Microsoft.AzureDevOps.Common.Activity" type="String" reportable="dimension">
<HELPTEXT>Type of work involved</HELPTEXT>
<SUGGESTEDVALUES>
<LISTITEM value="Development"/>
<LISTITEM value="Testing"/>
<LISTITEM value="Requirements"/>
<LISTITEM value="Design"/>
<LISTITEM value="Deployment"/>
<LISTITEM value="Documentation"/>
</SUGGESTEDVALUES>
</FIELD>TF402545: Element [elementName] requires that you include field [fieldName] in the definition of work item type [witName].
You should include a corresponding FIELD element in the named WIT definition for each field that you specify within the AddPanel section of the ProcessConfiguration.xml file.
You should also include a Control element within the FORM section of the named WIT.
ProcessConfiguration specifies two custom fields. However, these fields aren't defined in the UserStory.xml file.
<AddPanel>
<Fields>
<Field refname="System.Title" />
<Field refname="Fabrikam.Product" />
<Field refname="Fabrikam.Technology" />
</Fields>
</AddPanel>Missing FIELD elements added to the UserStory.xml file.
<FIELD name="Product" refname="Fabrikam.Product" type="String" reportable="dimension">
<FIELD name="Technology" refname="Fabrikam.Technology" type="String" reportable="dimension"> To support ProcessConfiguration element [elementName], work item type [witName] must define TypeField [typeField] (field refname [refName]).
In the ProcessConfiguration you created a TypeField with TypeFieldValues. In your work item type, reference that same TypeField.
ProcessConfiguration.xml
<TypeField refname="Custom.ApplicationType" type="ApplicationType">
<TypeFieldValues>
<TypeFieldValue value="Web application" type="WebApp" />
<TypeFieldValue value="Remote machine" type="RemoteMachine" />
<TypeFieldValue value="Client application" type="ClientApp" />
</TypeFieldValues>
</TypeField> FeedbackRequest.xml is using the Microsoft.AzureDevOps.Feedback.ApplicationType field when it should be using the Custom.ApplicationType field.
<FIELD name="Application Type" refname="Microsoft.AzureDevOps.Feedback.ApplicationType" type="String">
...
</FIELD>FeedbackRequest.xml
<FIELD name="Application Type" refname="Custom.ApplicationType" type="String">
...
</FIELD>TF402556: For field [refName] to be well defined, you must name it [fieldName] and set its type to [fieldType]. Provided [refName] is [fieldName] and type is [fieldType].
If you are on an on-premises server and running tfsMigrator, this error is generated when your process is out-of-date and a system field isn't properly defined. In most cases, use the witadmin /changefield command to properly rename the field.
Reserved System.XXX and Microsoft.AzureDevOps.XXX fields require name and type values.
| Field | Name | Type |
|---|---|---|
| System.Id | ID | Integer |
| System.Title | Title | String |
| Microsoft.AzureDevOps.Scheduling.StoryPoints | Story Points | Double |
| Microsoft.AzureDevOps.Scheduling.RemainingWork | Remaining Work | Double |
| Microsoft.AzureDevOps.Scheduling.OriginalEstimate | Original Estimate | Double |
| Microsoft.AzureDevOps.Scheduling.CompletedWork | Completed Work | Double |
TF402556: For field Microsoft.AzureDevOps.TCM.ReproSteps to be well defined, you must name it Repro Steps and set its type to HTML. Provided Microsoft.AzureDevOps.TCM.ReproSteps is My Repro Steps and type is HTML.
In Bug.xml, the friendly field name changed to "My Repro Steps."
<FIELD name="My Repro Steps" refname="Microsoft.AzureDevOps.TCM.ReproSteps" type="HTML">
<HELPTEXT>How to see the bug. End by contrasting expected with actual behavior.</HELPTEXT>
</FIELD> Bug.xml
<FIELD name="Repro Steps" refname="Microsoft.AzureDevOps.TCM.ReproSteps" type="HTML">
<HELPTEXT>How to see the bug. End by contrasting expected with actual behavior.</HELPTEXT>
</FIELD> TF402557: Inconsistent definitions exist for field [refName] in the following work item types: [witName]. Ensure that all references to a field have the same RefName, Name, and Type.
FIELD element definitions for fields with the same friendly name must be consistent across WITs.
Check to ensure that the refname, name, and type attributes are the same in each of your WIT definitions for the named field.
Bug.xml
<FIELD name="Hair Color" refname="MyCompany.CustomFields.HairColor" type="String" reportable="dimension" />UserStory.xml
<FIELD name="Hair Color 2" refname="MyCompany.CustomFields.HairColor" type="Double" reportable="dimension" />Notice that the name and type attributes differ from the Bug.xml work item type.
Bug.xml
<FIELD name="Hair Color" refname="MyCompany.CustomFields.HairColor" type="String" reportable="dimension" />UserStory.xml
<FIELD name="Hair Color" refname="MyCompany.CustomFields.HairColor" type="String" reportable="dimension" />TF402558: The definition of field [refName] is inconsistent with an existing field. The type is [typeName] but should be [typeName].
Edit the WIT file that contains the named field to ensure the specified type attribute value is consistent across all WITs.
You defined [n] fields for the named WIT which exceeds the allowed number of fields for any one WIT.
Edit the named WIT and remove the extra custom fields to reduce the total number of fields to be within the allowed limit.
You defined [n] fields for all WITs defined in the process. Only [fieldLimit] are allowed, which includes System.XXX and Microsoft.AzureDevOps.XXX namespace fields and custom fields.
Review the FIELDS and WORKFLOW sections and determine which custom fields to remove.
TF402566: You defined [n] field rules for work item type [witName]. A maximum of [ruleLimit] is allowed.
You defined [n] field rules for the named WIT which exceeds the allowed number of field rules for any one WIT.
Edit the named WIT and remove the extra field rules to reduce the total number of fields to be within the allowed limit.
TF402568: You defined [n] fields with syncnamechanges="true" for work item type [witName]. A maximum of 64 is allowed.
The number of fields with syncnamechanges="true" defined for the named WIT exceeds the allowed limit, which includes System.XXX and Microsoft.AzureDevOps.XXX namespace fields and custom fields.
Review the FIELDS section of the named WIT and determine which custom fields to remove or modify.
<FIELD name="Assigned To" refname="System.AssignedTo" type="String" reportable="dimension" syncnamechanges="true" >
...
</FIELD>TF402569: You defined [n] values for field [fieldName] in work item type [witName]. A maximum of [listLimit] is allowed.
The number of LISTITEM elements defined for the named field in the named WIT exceeds the allowed limit.
Edit the named WIT to reduce the number ofLISTITEM elements so as not to exceed the allowed maximum.
<FIELD name="Favorite Color" refname="MyCompany.CustomFields.FavColor" type="String" reportable="dimension">
<ALLOWEDVALUES>
<LISTITEM value="Color1" />
<LISTITEM value="Color2" />
<LISTITEM value="Color3" />
. . .
</ALLOWEDVALUES>
</FIELD>Notice the bug and user story refname values are different.
The "for" and "not" attributes aren't supported at all for any field rule for import to Azure DevOps Services.
Review the FIELDS and WORKFLOW sections for the presence of "for" and "not" attributes and remove them.
<FIELD name="Title">
<READONLY for="Dev Team" not="Test Team" />
</FIELD><FIELD name="Title">
<READONLY />
</FIELD>Most System and Microsoft.AzureDevOps fields don't support rules. For more information, see Rules and rule evaluation.
Edit the definition files for work item types that contain the named field to remove the field rules specified for it.
- Don't alter reserved fields: Don't alter any fields defined in the reserved namespaces
System.*XXX*andMicrosoft.AzureDevOps.*XXX*. - Define custom fields: To have a different list of values in the pick list fields, define your own custom field.
Bug.xml has the priority field defined, but has a different list of values than expected.
<FIELD name="Priority" refname="Microsoft.AzureDevOps.Common.Priority" type="Integer" reportable="dimension">
<ALLOWEDVALUES expanditems="true">
<LISTITEM value="0"/>
<LISTITEM value="1"/>
<LISTITEM value="2"/>
</ALLOWEDVALUES>
<DEFAULT from="value" value="2" />
</FIELD>Corrected Bug.xml including a new field
<FIELD name="Priority" refname="Microsoft.AzureDevOps.Common.Priority" type="Integer" reportable="dimension">
<HELPTEXT>Business importance. 1=must fix; 4=unimportant.</HELPTEXT>
<ALLOWEDVALUES expanditems="true">
<LISTITEM value="1"/>
<LISTITEM value="2"/>
<LISTITEM value="3"/>
<LISTITEM value="4"/>
</ALLOWEDVALUES>
<DEFAULT from="value" value="2" />
</FIELD>
<FIELD name="Custom Priority" refname="Custom.Priority" type="Integer" reportable="dimension">
<HELPTEXT>Business importance. 1=must fix; 4=unimportant.</HELPTEXT>
<ALLOWEDVALUES expanditems="true">
<LISTITEM value="0"/>
<LISTITEM value="1"/>
<LISTITEM value="2"/>
</ALLOWEDVALUES>
<DEFAULT from="value" value="2" />
</FIELD>VS402504: User or group can't be found [project]\Group Name. Verify that the users and groups used in your work item type definition exist.
Custom project scoped groups aren't supported. You can only reference account level scoped groups.
Bug.xml is referencing a project scoped group.
... "[project]\Organization Leaders"
Create a new account (collection) level group "Organization Leaders" and reference it accordingly in the XML.
... "[global]\Organization Leaders"
Note
A freshly created global group might take a little while before the import process locates it.
TF237094: Field name '[fieldName]' is used by the field '[refName]', so it can't be used by the field '[refName]'.
Field name already exist with that same name on a different field. Change the name of the field.
TF237094: Field name 'External ID' is used by the field 'Custom.ExistingField.ExternalID', so it cannot be used by the field 'Custom.NewField.ExternalID'.
Change the field name of Custom.NewField.ExternalID
<FIELD name="External ID" refname="Custom.NewField.ExternalID" type="string" reportable="dimension" />VS403104: Work item type [witName] references the required field [refName] which isn't included in all layouts.
This warning is generated if you have a required field in a work item type that is referenced in the <Layout> node but not the <WebLayout>. The <WebLayout> is used to modify the layout of the new form.
VS403073: Group & <Group Name>: violates the rule that a group can only contain a single HTML or WebPage control preceded by label controls.
In the new form layout, a group can only contain one HTMLFieldControl or WebPageControl.
<Section>
<Group Label="Description:">
<Control Label="Reason For Request:" Type="HtmlFieldControl" FieldName="System.Description" />
<Control Label="Business Case For Request:" Type="HtmlFieldControl" FieldName="MB.BusinessCase" />
</Group>
</Section>To resolve this error, create two separate groups that contain one control each.
<Section>
<Group Label="Reason for Request">
<Control Label="Reason For Request:" Type="HtmlFieldControl" FieldName="System.Description" />
</Group>
<Group Label="Business Case">
<Control Label="Business Case For Request" Type="HtmlFieldControl" FieldName="Custom.BusinessCase" />
</Group>
</Section>TF402594: File violates the schema with the following error: The element 'Control' can't contain child element 'Link' because the parent element's content model is empty.
<Control Type="FieldControl" FieldName="customfield.foo" Label="Foo" LabelPosition="Left">
<Link UrlRoot="http://www.visualstudio.microsoft.com/team-services/" />
</Control> <Control Type="FieldControl" FieldName="System.Title" LabelPosition="Left" Label="Title 1"
<LabelText>
<Text>
<Link UrlRoot="http://www.visualstudio.microsoft.com/team-services/" />
Title 2
</Text>
</LabelText>
</Control> TF402567: You defined [n] workflow states for work item type [witName]. A maximum of [stateLimit] is allowed.
You defined [n] workflow states for the named WIT which exceeds the allowed number of workflow states for any one WIT.
To reduce the total number of states to be within the allowed limit, edit the WORKFLOW section of the named WIT and remove the extra STATE elements.
TF402578: Field [refName] specifies friendly name [friendlyName] which is already in use by field [refName]. Friendly names must be unique across all field definitions.
Field names must be unique within the work item type.
<FIELD name="Foo" refname="MyCompany.CustomFields.Foo" type="String" reportable="dimension" />
<FIELD name="Foo" refname="MyCompany.CustomFields.Bar" type="String" reportable="dimension" />Notice there are two fields with the name <FIELD name="Foo".
<FIELD name="Foo" refname="MyCompany.CustomFields.Foo" type="String" reportable="dimension" />
<FIELD name="Bar" refname="MyCompany.CustomFields.Bar" type="String" reportable="dimension" />TF402579: Name [friendlyName] is used multiple times on different fields across the following work item types: [witNames]. Name for fields must be unique across the project collection.
Fields referencing the same refname="MyCompany.FieldName" must have the same friendly name FIELD name="fieldname" value.
Process A, Bug.xml
<FIELD name="Foo" refname="MyCompany.CustomFields.Foo" type="String" reportable="dimension" /> Process B, Bug.xml
<FIELD name="Bar" refname="MyCompany.CustomFields.Foo" type="String" reportable="dimension" /> Because both fields share the same reference name, refname="MyCompany.CustomFields.Foo",
they must also specify the same friendly name <FIELD name="Foo" across all processes
imported or to be imported to Azure DevOps.
WIT friendly names WORKITEMTYPE name="Name" must be unique within the process.
My Work Item A.xml
<WORKITEMTYPE name="My Work Item" refname="My.MyWorkItemA">My Work Item B.xml
<WORKITEMTYPE name="My Work Item" refname="My.MyWorkItemB">Notice how the WORKITEMTYPE name= is the same across both work item types.
My Work Item A.xml
<WORKITEMTYPE name="My Work Item A" refname="My.MyWorkItemA">My Work Item B.xml
<WORKITEMTYPE name="My Work Item B" refname="My.MyWorkItemB">WIT reference names refname="value" must be unique within the process.
Bug.xml
<WORKITEMTYPE name="Bug" refname="MyCompany.Name">UserStory.xml
<WORKITEMTYPE name="User Story" refname="MyCompany.Name"> Both refname values equal "MyCompany.Name"
Bug.xml
<WORKITEMTYPE name="Bug" refname="MyCompany.Bug">UserStory.xml
<WORKITEMTYPE name="User Story" refname="MyCompany.UserStory"> Custom controls aren't supported in Azure DevOps Services. Review the FORM section for the named WIT and remove any custom controls that are defined.
Type="OneViewMultiValueControl" specifies a custom control. Remove or replace this custom control to a supported control.
<Group Label="Engineering Alignment">
<Column PercentWidth="100">
<Control FieldName="Fabrikam.Content.Product" Type="FieldControl" Label="Product" LabelPosition="Left" />
<Control FieldName="Fabrikam.Content.Release" Type="FieldControl" Label="Milestone" LabelPosition="Left" />
<Control FieldName="Fabrikam.Content.Technology" Type="FabrikamMultiValueControl" Label="Technology" LabelPosition="Left" />
</Column>
</Group>