Developer Tools
Azure DevOps
Connect your AI to Azure DevOps
Engineering managers, developers, and DevOps and release engineers run their delivery through Azure DevOps, but the answers they need about stale pull requests, failing builds, sprint progress and what shipped sit across separate boards, repositories and pipelines. AI can pull those answers together in seconds, but only if it keeps to read-only access scoped to the Azure DevOps projects the connected account can see, and never exposes or infers data from projects outside that access.
Why it matters
Capabilities that matter most for Azure DevOps
01
Read-only by design
The connector exposes no actions, so AI can read Azure DevOps but never change a work item, merge a pull request or queue a build.
02
Work, code and delivery together
Work items, pull requests, commits, builds, pipeline runs, releases and iterations are all reachable, so one question can follow a change from a ticket to a deployment.
03
Ready-made tools and prompts
Popdock ships Get data tools for the Azure DevOps lists and prompts for stale pull requests, failing builds, sprint status and release summaries, so teams start from tested jobs.
03
Pairs with the rest of your stack
Cross-system prompts link Azure DevOps to Zendesk, Jira, GitHub, ServiceNow, Bugsnag, BugHerd and Ghost Inspector, so bugs, tickets and incidents tie back to the work behind them.
Use cases
Example AI Use Cases for Azure DevOps
scenario
-
Engineering has to decide how urgent a bug is, but the customers who wrote in about it are in Zendesk. Someone reads the work item, picks out the ticket numbers, then opens each ticket to find the requester and organization, and the open count is a guess.
What popdock provides
--
Name the work item and it reads it and its comments in Azure DevOps, collecting every Zendesk ticket number mentioned. It then pulls each ticket from Zendesk and lists the requester, organization, status and priority. If no ticket is quoted, it searches Zendesk by a phrase from the title and labels those hits as possible. Tickets that cannot be found are listed as not found, and nothing in Zendesk is changed.
Business outcome
---
Engineering sees which customers and organizations a bug affects, and how many tickets are still open, before deciding its priority.
scenario
-
Repositories collect branches that nobody owns any more. Working out which are stale, locked or far behind the default branch means opening each one, and nobody wants to clean up a branch that might still matter.
What popdock provides
--
Name a repository and it lists its branches with how far each has diverged from the default branch and when it was last touched. Stale, locked and diverged branches are grouped, each with a suggested cleanup action. It never suggests deleting the default branch or a branch with an active pull request, and it only reports: nothing is deleted or locked.
Business outcome
---
You get a short, safe cleanup list for a repository without opening each branch or risking one that is still in use.
scenario
-
Backlogs fill with items nobody owns, items nobody has touched in months and priority 1 items that have stalled. Reviewing them means filtering the board several ways and the review rarely happens.
What popdock provides
--
Name a project and it reads its open work items, then flags those that are unassigned, untouched for a set period, or priority 1 and neglected. Findings are grouped by area so each team sees its own. Nothing is reassigned or closed, and it says when results were capped.
Business outcome
---
Forgotten and stuck work is surfaced by area, so the backlog review has a list to act on instead of a hunt.
scenario
-
Critical bugs reported in BugHerd are meant to be worked as Azure DevOps work items, but there is no single view of how they are progressing. A manager has to open each task, find its work item, and check its state and due date.
What popdock provides
--
Choose a severity and it reads the matching BugHerd tasks, finds the linked Azure DevOps work item for each, and groups the tasks by the state of that work item. Tasks that are overdue or have no linked work item are flagged, and broken links are reported rather than dropped. Both systems are only read.
Business outcome
---
Managers see how critical bugs are moving through delivery in one digest, with overdue and unlinked ones called out.
scenario
-
High-volume Bugsnag errors are supposed to have an Azure DevOps work item, but checking means comparing the two lists by hand. Serious errors that nobody tracks stay unowned until a customer complains.
What popdock provides
--
Give it an event threshold and it lists the open Bugsnag errors above it, then searches Azure DevOps for a work item tracking each one. The untracked errors are reported first, and errors whose work item is already closed are flagged. It limits how many it checks and says when more exist. Nothing is created in either system.
Business outcome
---
High-volume errors with no owner are found quickly, so they can be raised before they become incidents.
scenario
-
Deciding whether a pull request can merge means opening the reviewers, the comment threads and the merge status separately. It is easy to miss a rejected vote or an unresolved thread and merge too soon, or to hold a good change up.
What popdock provides
--
Give a pull request id and it reads its reviewers and their votes, every comment thread and its status, and the merge status. It then gives a ready or not-ready verdict with the reasons behind it. It never merges or approves anything, and it stops if the id is ambiguous or not found.
Business outcome
---
You know whether a pull request is ready to merge, and exactly what is blocking it if not, in one answer.
scenario
-
After a release goes out, someone compares the deployment time in Azure DevOps with the Ghost Inspector test runs by hand. It is easy to confuse failures that were already there with ones the release caused.
What popdock provides
--
Name a release and it reads its deployments from Azure DevOps, then looks at the Ghost Inspector test failures before and after each deployment. It reports the failures that are new since the release and the ones that were already failing. The result is correlation by time, not proof of cause. It only reads, and it stops if no deployment matches.
Business outcome
---
You can see which test failures are new since a release went out, so the team investigates the right ones first.
scenario
-
Release owners open each Jira issue that is in review and then hunt through Azure DevOps for its pull request and latest build. The check is repeated for every issue, and a missing build is easy to mistake for a failing one.
What popdock provides
--
Name a Jira status and it lists the issues in it, then looks in Azure DevOps for each issue's pull request, matched on the full issue key in the title, and its latest build result. Each issue shows the pull request state and the build outcome side by side. An issue with no build is recorded as having none, not as a failure. Both systems are only read.
Business outcome
---
Release owners see the delivery state of every issue in a status at a glance, with no per-issue hunt.
scenario
-
After a deployment, someone has to watch Zendesk to see whether support volume jumped. The release time is in Azure DevOps and the tickets are in Zendesk, so the comparison is done by eye and often skipped.
What popdock provides
--
Name a release and it finds its latest deployment in Azure DevOps, then counts the Zendesk tickets created in the 24 hours before and after it. It reports both counts and the ratio between them. If either window is empty it declines to compute a ratio, and it states that timing is correlation, not cause. Nothing is changed in Zendesk.
Business outcome
---
You see whether support volume moved after a release, with the limits of that signal stated plainly.
scenario
-
A team that builds in both Azure Pipelines and GitHub Actions has to open two systems to see whether a branch is failing in one, the other or both. Lining up the runs by hand is slow and the disagreements are the interesting part.
What popdock provides
--
Name a branch and it reads the recent Azure DevOps builds and the recent GitHub workflow runs for it, then compares the results. It flags where the two systems disagree, for example a green build in one and a red run in the other. If one side is empty or truncated it says so and reports what it has. It only reads, and every GitHub write action is off limits.
Business outcome
---
You see at a glance whether a branch's CI is healthy in both systems, and where they disagree.
scenario
-
CI pipeline status and end-to-end test suite status live in different tools. Days when the pipeline is green but the browser suite is red, or the reverse, go unnoticed because nobody lines the two up.
What popdock provides
--
Name a pipeline and a Ghost Inspector suite and it pairs each Azure DevOps pipeline run with the next suite result, then lists the pairs that disagree. Unfinished runs are skipped, and the time-pairing rule it used is stated. It stops if a name is ambiguous or one side is empty. Both systems are only read.
Business outcome
---
Mismatches between CI and end-to-end results are found and listed, so no red suite hides behind a green pipeline.
scenario
-
Failed pipeline runs go unreported when nobody checks whether ServiceNow already has an incident for them. Operations either raise duplicates or miss failures altogether, because the two systems are checked separately.
What popdock provides
--
Choose a time window and it lists the recent failed pipeline runs in Azure DevOps, then looks in ServiceNow for an incident or alert that matches each one. The result shows which failures are already known and which have nothing recorded. It may suggest where an incident is needed, but it never raises one. Both systems are only read.
Business outcome
---
Operations see which failed pipelines are already known to ServiceNow and which are not, before anyone raises a duplicate.
scenario
-
When a pipeline starts failing it often gets re-run several times before anyone works out what changed. Finding the first failing run and the commits since the last success means paging through run history and commit lists.
What popdock provides
--
Name a pipeline and it finds the first failing run after the last success, then lists the commits between the two. Likely causes are ranked from the changes themselves. Build logs are not available, so it says so and does not guess at error messages. Nothing is changed or re-run.
Business outcome
---
The team starts from a short list of suspect commits instead of re-running a failing pipeline and hoping.
scenario
-
Before filing a work item for a Bugsnag error, someone searches Azure DevOps to see if one already exists. The search is by hand and by keyword, so duplicates get filed or a tracked error looks untracked.
What popdock provides
--
Give a Bugsnag error and it reads the error, then searches Azure DevOps work items by the error id, class and message. You get a verdict of tracked, possibly tracked or untracked, with the matches behind it. Weak matches on the class name alone are labelled as weak. It creates nothing in either system.
Business outcome
---
You know whether an error already has a work item before anyone files a duplicate.
scenario
-
Bug reports in BugHerd are meant to become Azure DevOps work items, but some never do. Finding the untracked ones means scanning both tools by eye and guessing which work item might already cover a report.
What popdock provides
--
Choose a BugHerd project and it lists the tasks that have no linked work item, then searches Azure DevOps by title for likely matches. Matches are offered as suggestions and never stated as confirmed. Nothing is written, and no links are stored in either system.
Business outcome
---
Untracked bug reports are found and paired with likely work items, so nothing reported falls out of the delivery process.
scenario
-
Nobody checks whether the bugs that were closed ever got a regression test, so the same bugs come back. Doing it means reading recent closed work items and then searching the test tool for something that covers each one.
What popdock provides
--
Give a time window and it reads the recently closed bug work items in Azure DevOps, then looks in Ghost Inspector for tests that appear to cover each. A name match is treated as a hint, not as proof. It separates bugs it could not match from bugs with no coverage found. Nothing is created in either system.
Business outcome
---
Closed bugs without a regression test are listed, so the team can add coverage before the bug returns.
scenario
-
Working out which change introduced a Bugsnag error means reading the first-seen time in one tool and scrolling commit history, pushes and builds in another. It is slow and the answer is easy to get wrong.
What popdock provides
--
Give a Bugsnag error and it takes the time the error was first seen, then lists the Azure DevOps commits, pushes and builds in the window before it. Candidates are ranked by how closely they fit, and the result is described as circumstantial. It does not widen the window quietly, and it creates and changes nothing.
Business outcome
---
Developers start with a short, ranked list of suspect changes instead of reading history by hand.
scenario
-
A developer or support lead asked about a customer ticket searches Zendesk for it, then hunts through Azure DevOps to see whether anyone is working on it. The work item is often missed, so the customer is told nothing is happening.
What popdock provides
--
Give a Zendesk ticket and it reads the ticket and its comments, then finds the Azure DevOps work items that reference it. It reports each work item's state and owner. Links quoted in comments are kept apart from possible title matches, and a ticket with no work item is reported as untracked rather than guessed at. Nothing in Zendesk is changed.
Business outcome
---
You can tell a customer whether engineering is working on their ticket, and who owns it, in one answer.
scenario
-
Urgent customer tickets slip through when nobody checks whether engineering has a work item for them. The check means searching Zendesk for urgent tickets and then cross-searching Azure DevOps for each one by hand.
What popdock provides
--
Choose a time window and it lists the recent urgent open Zendesk tickets, then checks Azure DevOps for a work item tracking each. Matches are labelled confirmed or possible, and untracked means only that no link was found. It limits the size of the batch, says so when it does, and changes nothing in Zendesk.
Business outcome
---
Urgent tickets with no engineering owner are found early, before the customer has to chase.
scenario
-
Admins match Azure DevOps team members to Jira accounts by eye. Names differ, emails change and some people have left, so work assignments cannot be carried across reliably.
What popdock provides
--
Name an Azure DevOps team and it lists its members, then looks each one up in Jira by email. You get matches, name-only matches, inactive accounts and people with no Jira user. Only email matches are trusted; name-only and multiple matches are flagged as unconfirmed. Nothing is changed in either system.
Business outcome
---
Admins get a trustworthy user mapping between the two systems, with the doubtful matches clearly marked.
scenario
-
Matching BugHerd members to Azure DevOps identities by hand is slow, and name-only matches are error prone. A wrong match sends a bug to the wrong person.
What popdock provides
--
Name a BugHerd project and it lists its members, then matches each to an Azure DevOps user by email and lists those with no match. Matches on name alone are shown as suggestions, not as confirmed. It never adds members or changes assignees in either system.
Business outcome
---
You get a reliable BugHerd to Azure DevOps user mapping, with uncertain matches kept apart from confirmed ones.
scenario
-
Matching a team's members to ServiceNow accounts one by one is slow, and wrong when emails or names differ between systems. Incident and change assignment then lands on the wrong person or no one.
What popdock provides
--
Name an Azure DevOps team and it lists the members, then finds each one's ServiceNow user by email, falling back to name. Anyone with more than one match is listed separately rather than collapsed into one, and inactive or unmatched users are flagged. Both systems are only read.
Business outcome
---
Admins get a clear team to ServiceNow user mapping, with the ambiguous and inactive accounts called out.
scenario
-
Knowing which Bugsnag collaborator is which Azure DevOps person means comparing two user lists by hand. People appear under different names, and gaps on either side go unseen.
What popdock provides
--
Name a Bugsnag organization and it lists the collaborators, then matches each to an Azure DevOps user by email. Gaps on both sides are reported. Matches on name alone are marked low confidence, and ambiguous matches are listed without choosing one. Neither system is changed.
Business outcome
---
You see exactly who is in one system and not the other, with name-only matches flagged as low confidence.
scenario
-
To see one person's load across engineering and support, you look them up in both Azure DevOps and Zendesk. The two systems often spell the same person's name differently, so the lookup is slow and uncertain.
What popdock provides
--
Give a person's email and it finds them in Azure DevOps and in Zendesk, then reports their open work items and open tickets. Email is the key; matches on name alone are flagged as possible. If a name matches several people it stops and asks rather than choosing. Nothing is changed in Zendesk or Azure DevOps.
Business outcome
---
Leaders see one person's combined engineering and support load without cross-searching two systems.
scenario
-
Branch lists in Azure DevOps and GitHub drift apart when a repository is mirrored. Stale or missing branches are found only by putting the two lists side by side and checking them by eye.
What popdock provides
--
Name a repository and it reads the branches in Azure DevOps and in GitHub, then compares the names. Branches that exist on only one side are listed for each. If one side is empty or truncated, it says so and reports what it has. It only reads, and every GitHub write action is off limits.
Business outcome
---
Teams see which branches exist on only one side of a mirror, so drift is fixed deliberately.
scenario
-
Teams that mirror code between Azure DevOps and GitHub compare commit lists by hand. A commit that never synced is easy to miss until something is found to be missing in production.
What popdock provides
--
Name an Azure DevOps repository and its GitHub counterpart and it reads the recent commits from both, then lists the commits missing on either side. If one side is empty or truncated it says so and reports partial results. It only reads, and every GitHub write action is off limits.
Business outcome
---
Commits that never synced are found quickly, so a mirror can be trusted or repaired with evidence.
scenario
-
Checking that every deployed release had an approved change is a manual cross-check between Azure DevOps and ServiceNow. It takes time and tends to be skipped, so unapproved deployments are found late.
What popdock provides
--
Choose a time window and it reads recent Azure DevOps deployments and the ServiceNow change requests, then reports which deployments are covered by an approved change, which have an unapproved one and which have none. Each row states how confident the match is. Change requests are never created or edited.
Business outcome
---
Operations and audit teams see which deployments lacked an approved change, with the confidence of each match stated.
scenario
-
Work items and GitHub issues for the same problem are tracked separately, so gaps go unnoticed. Someone compares the two lists by eye and stale references to closed issues stay in work items.
What popdock provides
--
Name a project and a GitHub repository and it matches open Azure DevOps work items to GitHub issues, then lists the unmatched items and any stale references. If a side is empty or truncated it says so and reports partial results. It only reads, and every GitHub write action is off limits.
Business outcome
---
Teams see which work has no counterpart on the other side, so duplicated and orphaned tracking is cleaned up.
scenario
-
Teams that track work in both Azure DevOps and Jira compare states and assignees by hand. A work item marked done on one side and still open on the other goes unnoticed until a status meeting.
What popdock provides
--
Name a work item state and it matches those Azure DevOps work items to their Jira issues, then tabulates where state or assignee differs. It lists the state mapping it used, never guesses at a loose match, and shows ambiguous matches separately. Both systems are only read.
Business outcome
---
Drift between the two trackers is shown in one table, so status and ownership can be corrected where they differ.
scenario
-
Someone compares BugHerd task statuses with Azure DevOps work items by hand. Tasks that drifted out of sync, for example done in one tool and open in the other, are missed.
What popdock provides
--
Name a BugHerd project and it reads the tasks that carry a work item id, looks up each work item in Azure DevOps, and reports where the statuses disagree. Work items that cannot be found and ids that are not numbers are flagged rather than guessed at. Both systems are only read, and BugHerd write actions are off limits.
Business outcome
---
Status drift between BugHerd and Azure DevOps is found and listed, so bug reporters and developers see the same state.
scenario
-
Sprint status is assembled by hand from the board and goes stale before the stand-up. Counting work items by state and working out which are at risk is repeated every sprint.
What popdock provides
--
Name a team and it reads the current iteration, then reports its dates, work item counts by state and the items that look at risk. It states which states it counted as done and says when results were capped. It only reads, so no work item is changed.
Business outcome
---
The team starts the stand-up with an accurate sprint summary instead of building one.
scenario
-
Overloaded team members are spotted only after the sprint slips. Comparing each person's capacity with the work assigned to them means reading the capacity page and the board separately.
What popdock provides
--
Name a team and it compares each member's capacity for the current iteration with their assigned open work. Members whose load looks heavy are shown first. It notes that hour estimates are not available, so it compares counts of work items. It only reads and changes nothing.
Business outcome
---
Managers see who is carrying too much before the sprint slips, while work can still be rebalanced.
scenario
-
Working out how a work item reached its current state means paging through its revisions and comments. Reopenings and long idle gaps are buried in the history.
What popdock provides
--
Give a work item id and it builds a dated timeline of its revisions and comments. Reopenings and idle gaps are flagged. If the item is not found it checks deleted items before giving up. It does not claim field-level differences it cannot see, and it changes nothing.
Business outcome
---
You understand how a work item got here, including reopenings and stalls, without paging through its history.
scenario
-
Release health is spread across releases and environments, so failed deployments and slow stages are missed. Reading each release and each environment one at a time takes longer than the release itself.
What popdock provides
--
Name a release definition and it summarises its recent releases and the per-environment deployment results and durations. Failures and slow stages are shown first. It does not infer approvals it cannot see, and it stops if the definition name is ambiguous. It only reads.
Business outcome
---
Release health across environments is clear at a glance, with failures and slow stages standing out.
scenario
-
Engineering leads have no quick view of what is actually happening in a repository. Commits, pushes, pull requests and diverging branches sit on separate pages, and the picture is out of date by the time it is assembled.
What popdock provides
--
Name a repository and a time window and it summarises the commits, pushes, pull requests and contributors in that window, along with branches that have diverged. It presents activity, not performance rankings of individuals. It only reads and changes nothing.
Business outcome
---
Leads get a current picture of a repository's activity without assembling it from several pages.
scenario
-
Working out whether a reported bug was fixed means hopping from the BugHerd task to its work item, then to the pull requests and builds. The path is manual and each hop can be wrong.
What popdock provides
--
Give a BugHerd task and it follows it to its Azure DevOps work item, then to the related pull requests and builds, and reports a timeline of what happened. It stops if a match is ambiguous and says when a match is by title only. Both systems are only read.
Business outcome
---
You can see whether a reported bug was fixed, and when, from one timeline instead of four screens.
scenario
-
Matching a Bugsnag release to its Azure DevOps commit and build means copying versions and revisions between two tools by hand. Mismatches go unnoticed and a deployed version can differ from the one reported.
What popdock provides
--
Name a Bugsnag release and it looks up the release, then finds the matching Azure DevOps commit, build and release record. It reports how well they agree. When the join falls back to version text it says confidence is low, and if there are several matches it lists them without picking one. Neither system is changed.
Business outcome
---
You know which code a Bugsnag release actually contains, and how sure the match is.
scenario
-
When a browser test starts failing, a developer hunts through commits, pull requests and builds to guess what broke it. Without the time of the first failure it is easy to pick the wrong change.
What popdock provides
--
Name a Ghost Inspector test and it finds its first failure, then lists the Azure DevOps commits, pull requests and pipeline runs just before it. It stops if the test name is ambiguous or the test is passing. It presents candidates and not a verdict, and it only reads.
Business outcome
---
Developers start from a short list of candidate changes for a new test failure instead of guessing.
scenario
-
Someone searches Azure DevOps by hand for the work behind a Jira issue. Pull requests and work items that only mention the key in a title are easy to miss, so the two sides look further apart than they are.
What popdock provides
--
Give a Jira issue and it reads it, then finds the Azure DevOps work items and pull requests that reference its exact key. It reports whether the two sides agree on state. If nothing refers to the key it says there is no traceable work instead of guessing. Both systems are only read.
Business outcome
---
You see the Azure DevOps work behind a Jira issue and whether the two agree, without a manual search.
scenario
-
Finding everything that happened to one work item means searching Azure DevOps comments, then GitHub issues and commits by hand. The history is in two places and rarely in one order.
What popdock provides
--
Give a work item id and it builds one merged timeline across Azure DevOps and GitHub. It combines the work item's comments and changes with related GitHub issues and commits. If a side is empty or truncated it says so and reports partial results. It only reads, and every GitHub write action is off limits.
Business outcome
---
You get one ordered history for a work item across both systems, instead of stitching it together.
scenario
-
Someone searches ServiceNow by hand to see which incidents and problems relate to a work item. Records that only mention it in text are missed, so engineering does not see the full operational impact.
What popdock provides
--
Give a work item id and it reads the work item and its comments from Azure DevOps, then searches ServiceNow incidents and problems for matches and reports them. Matches that rest on the title alone are labelled probable. ServiceNow records are never created or updated. Both systems are only read.
Business outcome
---
Developers see which incidents and problems relate to a work item, so the operational impact is part of the fix.
scenario
-
Pull requests sit unreviewed for days and nobody notices who is blocking them. Finding the quiet ones means filtering the list and opening each pull request to see its reviewers and threads.
What popdock provides
--
Name a repository and it lists the active pull requests with no recent activity, then names the missing reviewers and the open comment threads on each. Draft pull requests are skipped. It limits how many it examines in depth and says what it skipped. It only reads: nothing is approved, commented on or merged.
Business outcome
---
Stalled pull requests are found with the people and threads holding them up, so reviews get unstuck.
No items found.
Ready to unlock your data?
Start building tools that turn your business systems into AI superpowers
Join forward-thinking companies that are transforming their operations with intelligent, secure AI automation.