To track user acceptance testing in Azure DevOps, add custom fields to your work items by editing an inherited process: Project Settings, then Process, then the work item type, then New field. Use work item fields (for example a UAT status on the Bug type) when stakeholders need to see and query the data. Use test run fields only when an integration will read the data through the REST API, because those values don’t show up in the standard test UI.

The rest of this guide covers which fields are worth adding, how to add them without breaking other teams’ boards, and where the limits are.

TL;DR

• Custom work item fields (UAT Status, UAT Sign-off Date, Business Owner) are visible on forms, boards and queries. They are the right default for UAT.
• Test run and test result custom fields are for categorical metadata only. As of Microsoft’s current documentation, values are capped at 1 KB and are read through the REST API, not shown in the test UI.
• Changes to an inherited process apply to every project that uses it. Trial them in a separate test project first.
• Field names are shared across the organization, so choose unique, descriptive names before you scale.
• Fields hold structured data. Rich UAT feedback (recordings, transcripts, steps) belongs in the ticket description and attachments, ideally captured before it reaches the backlog.

Table of Contents

• Two kinds of custom fields, and why UAT teams mix them up
• Which custom fields are worth adding for UAT
• How to add a custom field to an inherited process
• Limits and gotchas to plan around
• Test run custom fields: useful, but narrow
• Test your changes before they reach every board
• From fields to a working UAT loop
• Our perspective: fields should receive data, not demand it
• Where Wezard fits
• FAQ
• Sources

Two kinds of custom fields, and why UAT teams mix them up

Azure DevOps has two separate places to add custom fields, and they behave differently.

Work item fields live on Bugs, User Stories, Issues, Test Cases and any custom work item type. You add them by customizing an inherited process, and they appear directly on the form. Microsoft’s guide to adding and managing fields for an inherited process describes how you can add a field, make it required or optional, and place it in a group on the layout.

Test run and test result fields store custom data against a test run or an individual result in Azure Test Plans. According to the Azure Test Plans custom fields documentation, a single project can define up to 100 of them, and a project administrator creates them.

The confusion starts because both are called “custom fields” in search results. A thread on adding a “UAT Sent Date” and “UAT Approved Date” to User Stories and Issues is a work item question. A thread about custom fields on test runs is a different feature with different constraints.

Our practical rule, which matches the guidance in Microsoft’s test run documentation: if a business analyst or project manager needs to see it in a query or on a board, it is a work item field.

Which custom fields are worth adding for UAT

Resist the urge to mirror your whole UAT spreadsheet in Azure DevOps. Every field is something a tester must fill in or ignore. Start with a short list and add only when a report demands it.

Fields on the Bug (or Issue) type

• UAT Status (pick list): Not Started, In Review, Accepted, Rejected, Deferred. Keep it to five values or fewer.
• UAT Cycle (pick list or string): for example “Release 4.2 UAT”. This lets you filter one acceptance round without relying on iteration paths.
• Business Impact (pick list): Blocker, Workaround exists, Cosmetic. Testers who work in the business, not in engineering, can judge this better than severity.
• Environment (pick list): UAT, Staging, Pre-prod. It stops “works on my machine” disputes.
• Reported By (Business Unit) (pick list): useful for routing questions back to the right stakeholder.

Fields on the User Story or Feature type

• UAT Sent Date and UAT Approved Date (date/time): these answer “how long does acceptance take?” without anyone building a spreadsheet.
• Business Owner / Approver (identity): the person who signs off.
• Sign-off Reference (string): a link or ID for the approval email or document, if your compliance rules need one. Our guide to signing off test cases after successful UAT covers what that record should contain.

Fields that don’t belong

Steps to reproduce, long descriptions, transcripts and pasted logs should not be custom fields. Keep them in the description, repro steps and attachments. Rich feedback in a field is a poor fit, as the next sections show.

How to add a custom field to an inherited process

The steps below follow Microsoft’s quickstart on adding a custom field to an inherited process. Menu names can shift between releases, so check against the current page.

1. Confirm permissions. Creating or editing a process requires membership in the Project Collection Administrators group or specific collection-level permissions, per the inherited process field guide.
2. Open the process. Go to Organization Settings, then Process. System processes (Agile, Scrum, CMMI, Basic) are locked, so create an inherited process from the one your project uses and move your project to it.
3. Choose the work item type. Select Bug, User Story, Issue or whichever type should carry the field.
4. Add the field. Select New field, enter a name, pick a type (text, picklist, date/time, identity, boolean and so on), and add a description. The description appears as help text for testers, so use it.
5. Set behavior. Mark the field required if every ticket must have it, and set a default value if one exists. On the Layout tab, choose the page and group where it appears.
6. Check the reference name. Microsoft notes that a custom field in an inherited process gets a reference name prefixed with Custom, as explained on the work item fields reference. You will need that name in queries, the REST API and any automation.
7. Test it. Create a work item, fill in the field, save, and run a query that filters on it.

Make fields required with care

A required field on the form is a good way to get clean data, and a good way to get junk. If a business user doesn’t know the answer, they pick the first value in the list. Make a field required only when a sensible default or an obvious answer exists. For “UAT Status”, a default of “Not Started” and a required flag works well. For “Business Impact”, consider leaving it optional and having the triager fill it in.

Limits and gotchas to plan around

Field names are organization-wide. Microsoft’s documentation on process inheritance and the fields reference explain that the system defines fields at the organization level and shares them across projects. Name a field “Status” or “Date” and you will collide with something. Prefer “UAT Status” or “UAT Approved Date”.

There is a per-type ceiling. The inherited process documentation lists a limit of 64 custom fields per work item type. You are unlikely to reach it with a UAT setup, but a process shared by many teams can fill up faster than you expect.

Fields can’t be team-specific. A frequent complaint on Q&A forums is that custom fields cannot be scoped to one team inside a project. They belong to the process. If two teams want different UAT fields, they need different processes, or you agree on one set.

States are a different mechanism. If you need a “Ready for UAT” or “UAT Failed” workflow step, that is a custom state, not a field. Custom states must also be connected by valid transitions or they won’t appear in the dropdown, as a Microsoft Q&A answer explains. Before you add many states, read our piece on using one or two gate states to cut bug noise.

Test run custom fields: useful, but narrow

Azure Test Plans lets you store custom data against a test run or result. Microsoft’s documentation says each project can have up to 100 such fields, and they support types including Bit, DateTime, Int, Float, String and Guid.

Two constraints matter for UAT.

You read them through the API. The values are available through REST calls such as Runs – Create and its update counterpart. Microsoft’s documentation does not describe them as displayed in the standard test UI, so a manual UAT triage session won’t surface them. Unless your team has a dashboard or script to read them, nobody will see the data.

Values are small. The RunCreateModel reference states that the value of a custom test field cannot exceed 1 KB. That is plenty for “Environment = UAT-West” or an external run ID. It is far too small for a session transcript or a paragraph of tester feedback.

So use test run fields for categorical metadata attached to a test session, and only when something will consume that metadata. For everything stakeholders need to read, use work item fields.

Test your changes before they reach every board

Microsoft’s guidance on customizing a project distinguishes locked fields and inherited fields from the fields you add, which you can fully customize. Because a change to an inherited process applies to every project that uses it, a mistaken required field can disrupt several teams at once.

The safe routine:

1. Create a copy of the process, or a sandbox project that uses a child of it.
2. Make the change there and create two or three sample work items.
3. Run the queries and dashboards your UAT leads rely on.
4. Only then apply the change to the production process, outside a UAT cycle.

This is ordinary change control. If your organization maps Azure administration to a security framework, the same discipline helps with audit evidence, and a walkthrough of mapping Azure to ISO 27001 for administrators shows how admins can look at the same environment from several angles to find gaps.

From fields to a working UAT loop

Fields give you structure. They don’t give you good tickets. Testers who are business users usually describe what they saw in a sentence or two, and the developer then asks for steps, screenshots and the environment. Required fields push that cost onto the tester, who is often doing UAT on top of a day job.

A workable pattern:

• Keep the field set small (UAT Status, UAT Cycle, Business Impact, Environment).
• Let the form default what it can: environment, cycle, reporter.
• Put the narrative in the description, with a recording or screenshots attached.
• Review new bugs on a fixed cadence and merge duplicates before developers see them.

For wider context, see our practical Azure DevOps UAT guide for QA teams, the Azure DevOps bug reporting best practices, and, if you are a project manager, Azure DevOps for PMs.

Our perspective: fields should receive data, not demand it

We build UAT software, and the pattern we see most often is this: teams respond to messy bug reports by adding more required fields. The form gets longer, testers get frustrated, and the quality of the free-text part, the part developers actually need, doesn’t improve.

We think the better split is to keep Azure DevOps fields for the small amount of structured data that drives queries and sign-off, and to capture the rich part another way. That is why Wezard records the screen, transcribes the tester’s spoken explanation in real time, and creates an enriched ticket. A tester can talk through what happened instead of typing steps into five fields.

The second thing we watch is duplicates. When ten testers hit the same defect, ten tickets land in the backlog, each with a slightly different UAT Status and description. Wezard’s AI checks for likely duplicates before the ticket is created in Azure DevOps, Jira or ServiceNow, so your fields describe unique issues. We claim up to a 40% reduction in duplicate noise compared with manual processes or basic feedback tools. That is our own figure, so test it in a pilot against your own backlog.

Our advice, whatever tool you use: decide what your stakeholders must query, add exactly those fields, and stop.

— Marketing

Where Wezard fits

If your team already has its UAT fields set up in Azure DevOps and the problem is the quality and volume of incoming tickets, take a look at our Azure DevOps integration. Testers submit by voice or video, the ticket arrives enriched with a recording and transcript, and duplicates are flagged before they reach your backlog. For the wider workflow, see the UAT testing feedback tool.

Plans are published on the pricing page: Starter at $25 per month, Team at $70 per month and Business at $160 per month. Enterprise has no published price.

FAQ

Can I add custom fields to Azure DevOps without changing the whole process?

Not for work items. In the inheritance model, you add fields by customizing an inherited process, and that change applies to every project using it. The workaround is to create a separate inherited process for the team that needs different fields and move only its project over.

Why can’t I see my custom test run fields in Azure Test Plans?

Per Microsoft’s documentation, custom fields for test runs and results are managed in project settings and accessed through the REST API. The standard test UI does not display them. If you need to see the data, pull it through the API into a dashboard or report, or use a work item field instead.

How many custom fields can I have?

The inherited process documentation lists a limit of 64 custom fields per work item type. For test runs and results, Microsoft states up to 100 custom fields per project. Each test field value is limited to 1 KB.

Should UAT status be a field or a state?

Use a state when the item moves through a workflow with rules, such as Ready for UAT to Accepted. Use a field when the value is an attribute you want to filter by without changing the workflow, such as UAT Cycle or Business Impact. Keep states to one or two gates, because every added state needs valid transitions.

Sources

• Add and manage fields for an inherited process, Microsoft Learn
• Add a custom field to an inherited process, Microsoft Learn
• List work item fields and attributes in Azure Boards, Microsoft Learn
• Process customization and inheritance, Microsoft Learn
• Custom fields for test runs and test results, Microsoft Learn
• Manage test runs in Azure DevOps Test Plans, Microsoft Learn
• Runs – Create, Azure DevOps REST API
• RunCreateModel interface, Microsoft Learn
• Customize a project, Microsoft Learn
• Custom state missing from work item, Microsoft Q&A

Recommended

• Azure DevOps UAT: A Practical Guide for QA Teams
• 9 UAT Environment Requirements BAs, PMs, and Testers Must Verify
• The UAT Change Management Process for QA and Release Teams
• UAT Testing Feedback Tool — Collect & Track UAT Bugs