When two bugs describe the same defect, mark the newer one with the Duplicate / Duplicate of link type and close it, keeping the original open as the canonical item. Before filing a new bug, search existing work items by title and area path first. If a match exists, link to it instead of creating a fresh entry that adds noise to the backlog.
TL;DR:
- Teams should always search existing bugs using specific title fragments, area path, tags, and comments before filing new reports to avoid duplicates.
- Properly linking and closing duplicate bugs in Azure Boards preserves history, with procedures varying by process template, and should include explanatory comments.
- Automation tools like Power Automate and scripts can detect duplicates at scale but must be supervised with dry runs to prevent merging unrelated issues.
- Reproducing issues, attaching detailed logs, and using guided intake forms significantly reduce duplicate reports at the source.
- Closing duplicates with links rather than deleting them maintains an accurate history and supports effective bug management.
Table of Contents
- How to Mark and Link Duplicate Bugs in Azure Boards
- How Do You Find Duplicate Bugs Before Filing a New One?
- Can You Automate Duplicate Detection at Scale?
- Prevention and Triage: Stopping Duplicates Before They’re Filed
- How to Close Duplicates Without Losing History
- Author Perspective: When Automation Creates More Problems Than It Solves
- Reduce Duplicate Bugs at the Source With Wezard
- Sources
How to Mark and Link Duplicate Bugs in Azure Boards
Azure Boards gives you a dedicated link type for exactly this situation. Open the newer bug, go to the Links tab, and add a link using the Duplicate type, pointing to the original work item. The original bug automatically receives the reciprocal Duplicate of link, so anyone viewing either item can trace the relationship in both directions. Microsoft’s own documentation on managing bugs in Azure Boards walks through this exact flow, and it’s the closest thing to an official standard for handling azure devops duplicate bugs.
Once the link is set, close the duplicate. What “closed” looks like depends on your process template:
- Agile process: move the bug to Closed, with Reason set to something like “Duplicate.”
- Scrum process: move it to Done, using the same duplicate reasoning in the comment.
- CMMI process: you’ll typically move through Resolved with reason Duplicate, then to Closed, since CMMI adds a verification gate that Agile and Scrum skip.
Don’t just close the item and walk away. Add a comment explaining which bug it duplicates and why, so future readers (including you, six months from now) understand the decision without digging through link history.
One setting trips up a lot of teams: how bugs behave depends on whether your team tracks bugs as requirements or as tasks. Under Project Settings > Team Configuration, the “track bugs as” toggle determines whether bugs show up on your product backlog alongside user stories or get buried under tasks on the sprint board. Microsoft’s guidance on work item visibility and backlog configuration covers this in detail. If your triage team can’t find a bug during a duplicate check, this setting is often the culprit, not a missing search filter.
How Do You Find Duplicate Bugs Before Filing a New One?
Most duplicate bugs get created because the reporter never searched properly, not because the search tools are inadequate. Azure Boards’ search box is more capable than people give it credit for, but it defaults to open items only, which is exactly where it misleads people.
Here’s a practical sequence to run before you hit “New Bug”:
- Search by exact title fragments. Use two or three distinctive words from the error message or symptom, not generic phrases like “login broken.”
- Switch the status filter to “All” so closed and resolved items show up too. A bug fixed three sprints ago and regressed will still be sitting there under Closed.
- Filter by area path and tags. If you know the feature area, narrow the search there first. Tags like
regressionorpayment-flowcut noise fast. - Check the comments, not just the title. Some bugs get renamed or clarified in a comment thread while the title stays vague. A search-by-title miss doesn’t mean there’s no match.
- Build a saved query with Work Item Type = Bug, Title Contains [your term], and State <> Removed. Save it to your team’s shared queries folder so triagers reuse it instead of reinventing search logic every sprint.
For teams running WIQL directly, there are two grouping strategies worth knowing. Exact-title grouping (WHERE [Title] = 'Login fails on Safari') works when your team enforces title conventions. Fuzzy matching (WHERE [Title] CONTAINS 'login' combined with area path and date filters) catches variants like “Login broken on Safari 17” that exact matching misses entirely. Use exact matching for automated cleanup scripts where precision matters more than recall, and fuzzy matching for manual triage sweeps where a human reviews the results anyway.
Pro Tip: Save two versions of the same query, one scoped to your current sprint and one scoped to the last 90 days. Duplicate bugs often surface when a tester reports something that was already fixed and reopened by a regression, and the 90-day view catches those patterns the sprint-scoped query misses.
Can You Automate Duplicate Detection at Scale?
Manual searching works fine until your backlog crosses a few thousand items, at which point pattern matching by eye stops being realistic. That’s where the Extended Analytics OData feed earns its place. It exposes non-hierarchical links, including the Duplicate relationship, in a queryable format that a script or Power Automate flow can consume directly. One detailed walkthrough on retrieving duplicate bugs through OData shows the query shape needed to pull duplicate link data out of a project with hundreds of bugs in minutes rather than hours.
A workable Power Automate pattern looks like this:
- Query the OData feed for all active bugs in a project, pulling Title, ID, Created Date, and Area Path.
- Normalize titles (lowercase, strip punctuation, trim whitespace) so near-identical bugs group together.
- Group the results by normalized title and flag any group with more than one item.
- Route flagged groups to a review queue rather than auto-closing anything on the first pass.
For teams comfortable scripting against the REST API directly, the pattern is similar but more granular: pull bugs via WIQL, group by exact or normalized title, sort each group by ID ascending, and treat the lowest ID as canonical. The cleanup script pattern documented in this Azure DevOps automation guide closes every item after the first in each group, adding a comment like “Duplicate of #4521” and applying the Duplicate link type automatically.
None of this should run unsupervised on day one. Every script or flow needs a dry-run mode that logs proposed changes without executing them, plus an audit trail of what got closed and why. A grouping bug that merges two unrelated items with similar wording can quietly destroy real bug history, and there’s no sourced figure on how often that happens across teams. Treat automation as a suggestion engine for a human reviewer until you’ve watched it run clean for several cycles.
Prevention and Triage: Stopping Duplicates Before They’re Filed
The cheapest duplicate to fix is the one that never gets created. Reproduction is the single biggest lever here: a bug that’s been reproduced in a clean environment with logs and screenshots attached is far less likely to become a near-duplicate of an existing report, because the reporter had to engage with the actual failure instead of describing a vague symptom from memory.
Build a short pre-file checklist and enforce it, even informally:
- Reproduce the issue at least once before filing.
- Note the exact environment (browser, OS, build number, test data used).
- Attach a screenshot, log excerpt, or recording, not just a text description.
- Search existing bugs using the sequence covered above.
- Check the area path owner if you’re unsure whether this is a known issue.
Standardized templates with required fields do a lot of the enforcement automatically. If “Repro Steps” and “Environment” are mandatory fields on your Bug work item type, a reporter can’t submit a one-line report that’s impossible to match against existing bugs. This ties directly into intake gating: some teams route all new bug reports through a triage queue rather than letting anyone file directly into the active backlog, especially in larger organizations where dozens of testers might be hitting the same regression simultaneously.
Guided intake forms that suggest possible existing matches as someone types a title catch a meaningful share of duplicates before they’re ever submitted, similar to how autocomplete suggestions work in a search engine. Marketplace extensions like the Duplicate Bug detection tool apply this kind of fuzzy matching directly inside the Azure Boards new-item form, flagging likely matches before the reporter finishes typing.
Pro Tip: If your team keeps seeing the same duplicate pattern (say, the same login bug reported by five different testers in one sprint), that’s usually a signal the bug itself needs faster visibility, not a signal your intake process is broken. Pin it or announce it in your team channel the moment it’s confirmed.
How to Close Duplicates Without Losing History
Deleting a duplicate bug destroys the paper trail. Closing it with a proper link preserves everything, including whatever unique detail the reporter happened to capture that the original bug lacked.
- Pick the canonical item. Default to the earliest-created bug (lowest ID) unless it’s missing critical detail the duplicate has, in which case migrate that detail over first.
- Add the comment and link. Write “Duplicate of #[ID]” in the comment field, then apply the Duplicate / Duplicate of link type between the two items, per the official Azure Boards bug management guidance.
- Move attachments selectively. If the duplicate has a screenshot or log the original lacks, attach it to the canonical item rather than leaving it stranded on a closed bug nobody will revisit.
- Verify with a query. Run a saved query filtering for Reason = Duplicate to confirm every closed item actually carries the link, catching any bug someone closed manually without linking it.
Author Perspective: When Automation Creates More Problems Than It Solves
Automated duplicate grouping earns its keep on high-volume, low-risk bugs, the fifteenth “button misaligned on mobile” report in a sprint. It’s a liability on ambiguous or high-risk items, where two reports that look similar in title might describe genuinely different root causes. Race conditions and overly aggressive fuzzy matching are the two failure modes worth watching. The fix isn’t avoiding automation, it’s dry-running everything, logging every closure, and having a person spot-check a sample each week.
— Marketing
Reduce Duplicate Bugs at the Source With Wezard
Every technique above works after a duplicate exists. Some tools record the tester’s screen and voice while they hit an issue, transcribe the report in real time, and run AI detection against existing tickets before anything gets submitted, to catch duplicates before they reach your backlog.
The Azure DevOps integration syncs flagged tickets directly into your project, preserving the recording and transcript as context so triage doesn’t lose the detail a text-only report would have missed. Pair it with a clear automation strategy, similar in spirit to the workflow-composition work described by Orchard, and intake stops being the bottleneck it usually is. If your team wants to see how it fits your current triage process, check out Wezard’s use cases or request a demo to test it against your own backlog.
Sources
- Define, capture, triage, and manage bugs in Azure Boards
- How to retrieve duplicate bugs
- ado-cleanup-duplicates.md (specweave)
