Azure DevOps has no single comment feature. It has several, in different places, with different rules: the Discussion section on a work item, comment threads on pull requests, comments at the bottom of a wiki page, and commit comments. Each behaves differently when you edit, search, resolve or audit it. This guide covers all four, then moves on to the habits that keep threads useful instead of noisy.
TL;DR
- Work item comments live in the Discussion section. You can edit or delete your own, and the change history is kept in the History tab.
- Use @ to mention people, # for work items and ! for pull requests. Azure DevOps has no CC, so a mention is the only way to notify someone.
- Pull request comments are threads with a status, and Azure Repos now shows unresolved versus total threads in the PR list.
- Discussion is not a queryable field. To find comments, you search the History field.
- Threads without owners and rules turn into message boards. Write a short commenting policy and assign someone to watch it.
Table of Contents
- The four places comments live in Azure DevOps
- Work item comments: the Discussion section
- Mentions, notifications and the missing CC
- Pull request comments
- Finding and auditing comments
- Comments through the REST API and tokens
- Governing comments so threads stay useful
- Our perspective: comments are where duplicate noise starts
- Comment practices for UAT in Azure DevOps
- Where Wezard fits
- FAQ
- Sources
The four places comments live in Azure DevOps
Before you decide how your team should comment, be clear about which kind of comment you mean.
| Where | What it is for | Who usually writes it |
|---|---|---|
| Work item Discussion | Questions, decisions and status on a bug, story or task | PMs, analysts, testers, developers |
| Pull request threads | Line-level and general review feedback on code | Developers, reviewers |
| Wiki page comments | Feedback on documentation | Anyone with wiki access |
| Commit comments | Notes on a single commit | Developers |
The distinction matters because they do not share history or notifications. A decision made in a pull request thread will not appear on the linked work item unless someone copies it there. If you run user acceptance testing, most of your useful conversation happens in the first row, which is where we spend most of this article.
Work item comments: the Discussion section
The Discussion section is where teams collaborate on a work item by adding and reviewing comments. Microsoft’s own documentation notes that a Discussion work item field does not exist, which has practical consequences we cover in the search section below.
Formatting, reactions and mentions
The Sprint 156 update added reactions on discussion comments and mentions for people, work items and pull requests. The mention triggers are:
- @ for a person
- # for a work item
- ! for a pull request
Reactions come in six emoji options. A thumbs up on “confirmed, I can reproduce this” is a cheap way to add signal without adding a comment that someone must read.
Editing and deleting
You can edit or delete comments you wrote. Per the Azure DevOps blog announcement, edited comments carry an “(edited)” mark and the changes are kept in the work item’s History tab. That audit trail is what makes the feature safe for regulated teams: nobody can quietly rewrite what they said last week.
One practical rule follows. If a comment is wrong, edit it rather than deleting it and posting again, so the thread stays readable and the history shows what changed.
Saving a comment is not saving a rule
The Discussion control is separate from ordinary fields. Saving a comment there does not run work item rules the way saving a field change does, so do not count on a comment to move a state or fill a field. If a decision needs to change the work item, change the field as well, then say why in the comment.
Mentions, notifications and the missing CC
A frequent surprise for people coming from email: Azure DevOps does not support CC-ing people on a discussion. You notify stakeholders with an @mention instead. Microsoft’s notifications FAQ also points out that a user needs at least a Basic access level to be mentioned, which often trips up admins testing permissions with a Stakeholder account.
That has a direct UAT consequence. Business users who review features often hold limited access levels. If you @mention a business approver and they never respond, check their access level before you assume they ignored you.
A few mention habits that work:
- Mention one person per question. “@Dana, can you confirm the discount applies to renewals?” gets an answer. “@everyone thoughts?” does not.
- Put the question first and the context after it, so the notification preview carries the ask.
- Link related items with #, not with pasted titles. Titles change, links do not.
- Use ! to point at the pull request that fixes a defect, so testers can see what to retest.
Pull request comments
Pull request comments are threads, not flat lists. Each thread belongs to a file and position (or to the PR in general), holds an opening comment plus replies, and carries a status. Microsoft’s API reference describes a comment thread as an initial comment with subsequent replies, plus metadata such as status and last-updated date.
Since the Sprint 273 update, Azure Repos shows unresolved comments in the pull request list in a simple unresolved-over-total format such as 1 / 3, so you can see review progress without opening every PR.
How to make that number mean something:
- Resolve with a reason. Close a thread only after the change is pushed or the disagreement is settled, and say which.
- Separate blockers from suggestions. Begin non-blocking remarks with a label such as “nit:” so the author knows what must change before merge.
- Keep the PR thread and the work item in step. If review changes the behavior a tester will see, add one line to the work item Discussion.
Finding and auditing comments
Because there is no Discussion field, you cannot write a query that filters on it. The documented workaround is to search through the History field, since the Discussion text is recorded in the work item history. For a PM trying to find every ticket where someone mentioned “refund”, that is the route: query on History contains the term, then open the results.
For audits, the History tab is also where you see who edited what. Combined with the “(edited)” mark, this gives you a defensible record of how a decision evolved.
Comments through the REST API and tokens
If you automate comments, for example to post test results back to work items, you will need to authenticate. Microsoft’s guidance on personal access tokens steers you toward Microsoft Entra tokens or managed identities where possible, because a PAT is a long-lived credential. If a tool does require one, keep the lifetime short and the scope minimal. Commenting on work items needs only a work item write scope, not full access.
Same page, a date to know: Microsoft’s documentation states that global PATs are slated for deprecation on December 1, 2026, so use organization-scoped tokens for any new automation and review old ones now.
Also, handle formatting with care. Posting formatted text through the API is a recurring question on community forums, and what renders correctly in the browser editor may need explicit formatting handling when posted by script. Test on a throwaway work item before you point a script at a live backlog.
Governing comments so threads stay useful
The technical features are the easy part. The hard part is that work item threads, like knowledge article comments in other tools, can drift into ungoverned message boards. A manager in a ServiceNow community discussion on comments for knowledge articles describes leaving the Comments field off for years because of this risk. The commonly suggested answer is clear commenting guidelines, plus subject matter experts who monitor and answer threads so work is not duplicated and information stays accurate.
That advice carries over to Azure DevOps and ServiceNow work equally. Teams that write down operating rules for shared workflows, as in these ops rules for team workflows aimed at engineering managers, tend to land on the same pattern: named ownership, written expectations and a regular review.
A lightweight policy for UAT work items can fit on one page:
- Purpose. Comments are for questions, decisions and evidence. Status belongs in the State field.
- Owner. Each work item has one named person who answers within an agreed time, such as one business day.
- Evidence. A claim that something fails includes steps, expected result, actual result and a recording or screenshot.
- Decisions. When a thread ends in a decision, the last comment states it in one sentence and references who agreed.
- No side channels. If a conversation moves to chat or a call, someone posts the outcome back.
- Duplicates. Before opening a new bug, search for it. If it exists, comment there and add your evidence instead of filing a second ticket.
Our perspective: comments are where duplicate noise starts
We build UAT software, so we see the same pattern across testing cycles. A business user hits a problem, finds no clear way to report it, and writes a vague comment on a loosely related ticket or opens a new ticket with a one-line description. Developers then spend their time asking for steps, and the backlog fills with near-identical items.
We think the fix has two parts. First, capture the issue where it happens: a screen recording, with the spoken explanation transcribed as the tester talks, gives a developer the context that a typed comment usually leaves out. Second, check for duplicates before the ticket reaches Jira or Azure DevOps, so the comment thread on the existing item gets the new evidence rather than a twin ticket gaining its own thread.
Comments are valuable when they are specific, owned and attached to the right item. Most of the problems teams blame on “too many comments” are really problems of too many items describing the same issue. For more on that, see our write-ups on reducing duplicate bugs in Azure Boards and on cutting bug noise with one or two gate states.
— Marketing
Comment practices for UAT in Azure DevOps
UAT is where comment discipline pays off most, because the people writing are not engineers. A few adjustments help.
Give testers a structure, not a blank box
Business users write better reports when prompted for what they did, what they expected and what happened. A guided form does that better than a free text field, which is the idea behind our piece on a ticket submission wizard for first-pass reproducibility.
Attach evidence to the comment
A recording or screenshot saves the round trip of “can you send a screenshot?”. Our guides on why context matters in bug reports and Azure DevOps bug reporting best practices go through what to include.
Agree who closes the loop
When a developer comments “fixed in the latest build”, the tester should reply with a retest result, and the business owner should sign off. Our walkthrough on signing off test cases after UAT covers that last step, and the Azure DevOps UAT guide for QA teams covers the wider process.
Remember ServiceNow works the same way
If your organization also runs ServiceNow, the same rules apply to work notes and comments: one purpose per field, a named owner, and a decision recorded at the end. The tool differs, the governance problem does not.
Where Wezard fits
Wezard is user acceptance testing software that records the tester’s screen, transcribes the issue in real time and uses AI to flag duplicate tickets before they reach your Jira or Azure DevOps backlog. It also integrates with ServiceNow. Testers can create tickets by voice or video, follow guided submission, and attach screenshots and files, and the result lands in the backlog as an enriched ticket rather than a bare comment.
Plans are published on the pricing page: Starter at $25 per month, Team at $70 per month and Business at $160 per month, with Enterprise available without a published price. If Azure DevOps is your backlog, start with our Azure DevOps integration page.
FAQ
Can I edit or delete a comment in an Azure DevOps work item?
Yes, for comments you wrote. Edited comments show an “(edited)” mark, and the changes are retained in the History tab, so the audit trail stays intact. Prefer editing to deleting when a comment is simply wrong.
How do I notify someone in an Azure DevOps comment?
Type @ followed by their name. Azure DevOps has no CC option, so a mention is the way to notify a stakeholder. The person needs at least a Basic access level to be mentioned.
Can I query work items by their comments?
Not directly, because there is no Discussion field to query. Discussion text is also recorded in the History field, so you can filter on History containing your search term and review the results.
How do I see which pull requests still have open comments?
Open the pull request list in Azure Repos. Following the Sprint 273 update, it shows unresolved versus total comment threads, such as 1 / 3, so you can spot reviews that are not finished.
Sources
- Azure DevOps docs: Capture comments in the Discussion section
- Sprint 156 Update: reactions and mentions
- Edit and Delete Discussion Comments on the Work Item
- Azure DevOps notifications FAQ
- Azure Repos Sprint 273 Update
- CommentThread interface, Azure DevOps extension API
- Use personal access tokens, Azure DevOps
- Comments on Knowledge Articles, ServiceNow Community
