Azure DevOps test case import error: “Invalid workitem field values found” (how to fix)

You prepare a CSV with new test cases, start the import, and Azure DevOps stops with Invalid workitem field values found. It doesn't say which field or which row. Here is what the error means, a CSV that works, the values that usually cause it, and a way to find the bad one.

New test cases from a file: Bulk Editor validates values against your process before publishing, and shows the reason per row. Free plan, 14-day Pro trial.
Install from the Marketplace See how it works

1. What the error means

Azure DevOps checks every imported row against the rules of your process, the same way it checks the work item form. If one value in one row is not allowed, the whole import is refused with this one general message. It does not name the field, and some people see [object Object] in the dialog instead of a reason. So the message tells you that something is wrong, not what.

In practice the cause is almost always one of a few values, listed below. The facts here come from the reports in a Microsoft Q&A thread where several people confirmed the fixes. Microsoft's own documentation for importing work items from CSV doesn't list Test Case explicitly among the types, so treat the import of test cases as something to test on a few rows first.

2. A minimal CSV that works

Start from the smallest file that can work, and add to it. Leave the ID column empty: a row without an ID is a new work item. Put the test case on its first row, with the title, and use one row per step. The title is only on the first row of a test case; the rows below it only have step columns.

ID,Work Item Type,Title,Test Step,Step Action,Step Expected,Priority
,Test Case,Sign in with a valid account,1,Open the sign-in page,The page shows the form,2
,,,2,Enter a valid user name and password,The Sign in button is enabled,
,,,3,Select Sign in,The dashboard is shown,
,Test Case,Sign in with a wrong password,1,Open the sign-in page,The page shows the form,2
,,,2,Enter a wrong password and select Sign in,An error message is shown,

Priority is optional. If you don't set State, the new test case gets the initial state of your process.

3. Common values that cause the error

State

A new work item must start in the initial state of its process. For a Test Case that is Design, not Ready or Closed. A file exported from existing test cases often has Ready in the State column, and importing it as new rows fails. Set State to Design or delete the column, and change the state afterwards (for example with a bulk edit in a query). If you use a custom process, check the name of the initial state in the process settings.

Area Path and Iteration Path

The path has to match an existing node exactly. It starts with the project name, uses backslashes, and has no Area or Iteration segment in the middle:

MyProject\Team A\Checkout
MyProject\Sprint 12

A typo, a different project name, forward slashes, a trailing space or a node that was renamed all make the row invalid. Copy the path from a work item that is in the right place. If you are not sure, leave the column out: the new test cases then get the default area and iteration of the project.

Shared Steps as the work item type

A row with Shared Steps as Work Item Type, or a step that refers to a shared step, is a common cause as well. Shared steps are a separate work item type with their own rules. Import plain Test Case rows first; see section 5 for shared steps.

Columns the import can't write

Read-only or system fields, such as Created By, Created Date, Changed By, Changed Date, Revision, or State Change Date. Remove them from the file.
An ID with a value. A filled ID means update an existing work item. For new test cases, the ID column has to be empty.
Names that aren't the field name. A column header has to be the field's name or reference name. A header from another tool, or a field that doesn't exist on the Test Case type in your process, is not accepted.
Values outside a pick list, such as a Priority of 5 (the field accepts 1 to 4) or a custom field with a list of allowed values.

4. Find the bad value

Since the message doesn't tell you, narrow it down:

Import one test case with only the columns from the minimal file: ID (empty), Work Item Type, Title, and one step. If that works, the problem is in a column you left out.
Add the columns back one at a time, importing a single test case each time. The column that brings the error back holds the invalid value.
If one column fails, look at the distinct values in it. Compare them to the allowed values in the work item form: State, Priority, and the two paths are the usual suspects.
Once the columns are fine, import the rest in chunks. If a chunk fails, halve it until you find the row.

Test cases that you created by mistake are easy to remove again: delete them from a query, or from the test suite.

5. Shared steps: create them after the import

Don't try to link shared steps in the file. Import the test cases with their normal steps first. Then create the shared steps in the test case form (select steps, then Create shared steps), or reference an existing shared step with Insert shared steps. This is slower for a large number of test cases, but it avoids the error and keeps the shared step work items valid.

Option: Bulk Editor

If you import test cases regularly, or the error keeps returning, Bulk Editor (made by us) can take over part of this. What it does, and what it doesn't:

Import from .xlsx (Pro): rows without an ID and with a Work Item Type become new work items in the project you opened Bulk Editor from. For test cases the layout is the same as the Test Plans export, with the columns Test Step, Step Action and Step Expected, one row per step. It imports .xlsx files, not CSV.
New rows in the grid (Pro): add rows in the grid itself and fill them in, so you don't need a file at all.
Validated before you publish: pick lists, required fields, states, and area and iteration paths come from your own process, including custom fields. A row with an invalid value is shown with the reason on that row, so you see which field is wrong before anything is saved.
Steps: edit the steps of existing test cases in a table (Pro). Shared steps are shown but not rewritten.

The free plan can open, validate and export; importing and creating work items need Pro (14-day trial). Bulk Editor works on Azure DevOps Services and Azure DevOps Server 2022 or later.

Install Bulk Editor

Related guides

Not affiliated with Microsoft. “Azure DevOps” and “Excel” are trademarks of Microsoft. Questions? Email support@jr-devtools.com.