--- title: "Azure DevOps Integration" description: "Connect AI agents to Azure DevOps. Agents create and update work items, run WIQL queries, manage Git repositories and pull requests, queue builds and pipeline runs, and track sprint iterations across a single organization." url: https://flowrunner.ai/integrations/azure-devops date_modified: 2026-08-01T02:40:32-07:00 --- # Azure DevOps [Developer Tools](https://flowrunner.ai/integrations/category/developer-infrastructure) Connect AI agents to Azure DevOps. Agents create and update work items, run WIQL queries, manage Git repositories and pull requests, queue builds and pipeline runs, and track sprint iterations across a single organization. [Verified](https://flowrunner.ai/integrations/verified "What does verified mean?") · 28 actions · Basic auth · available [Azure DevOps website](https://azure.microsoft.com/en-us/products/devops) · [Platform Documentation](https://learn.microsoft.com/en-us/rest/api/azure/devops/) · Capability data verified 2026-08-12 1. A production alert or support escalation arrives from the monitoring stack 2. Agent pulls the error details, affected component, and reporting context 3. Run WIQL Query searches for an existing open Bug on the same component 4. Create Work Item opens a Bug with repro details, links, and the right area path 5. Add Comment to Work Item threads the alert context and the team channel gets a summary 6. The team lead triages the Bug into the sprint or challenges the severity ## What This Integration Enables Azure DevOps holds the whole delivery chain in one organization: work items, Git repositories, pull requests, and pipelines. That makes it the natural place for agents to do the traceability work engineers resent: filing work items from alerts, running WIQL queries for reports, annotating pull requests, and queueing builds. FlowRunner agents work across that entire chain with this connector, and they respect its one non-negotiable boundary. The boundary is release authority. An agent can assemble everything a release decision needs, the commits, the linked work items, the failing checks. What it does not do is ship on its own. Completing a pull request into the default branch and running the production pipeline are [human-in-the-loop](https://flowrunner.ai/concepts/human-in-the-loop) moments, because shipped software cannot be quietly unshipped. ### Without FlowRunner **Alerts and work items diverge**: Production issues live in the monitoring tool while the sprint board shows a different reality **Duplicate bugs**: The same failure gets filed three times because nobody searched before filing **Releases on tribal knowledge**: What is actually in the release lives in someone's terminal history ### With FlowRunner **One trail from alert to fix**: Every escalation becomes a work item with the evidence attached and linked **Filed once, threaded after**: New reports of a known failure land as comments on the existing Bug **Releases with a manifest**: The release run starts from an assembled summary of commits and linked work items ## Use Case Scenarios ### Alerts that file themselves, once A production error spikes in the monitoring stack. The agent extracts the failure signature, runs Run WIQL Query to check for an open Bug on the same component, and finds one of two situations. If a Bug exists, Add Comment to Work Item threads the new occurrence with timestamps and links, so the record shows frequency instead of spawning duplicates. If not, Create Work Item opens the Bug with repro details and the alert payload. Either way, the team channel in [Slack](https://flowrunner.ai/integrations/slack) gets a one-line summary with the work item link. Paired with [GitHub](https://flowrunner.ai/integrations/github), a cross-repo PR can open a tracking Task the same way. ### Sprint reporting without the Friday scramble On a schedule, the agent calls List Team Iterations to resolve the current sprint, runs a WIQL query for its work items, and pulls full details in bulk with Get Work Items Batch. The output becomes a digest: what moved, what stalled, what entered mid-sprint. Because the agent reads the same fields the board shows, the report and the board never disagree, and the team lead spends standup on the stalled items instead of on assembling the list. ### A release run that a person pulls the trigger on When a release is proposed, the agent builds the manifest: List Commits since the last release tag, the pull requests merged in the window from List Pull Requests, and the work items they reference. It posts the assembled summary to the release manager. On approval, Run Pipeline queues the production pipeline on the release branch, and Get Pipeline Run polls until the state resolves. A failed result goes straight back to the channel with the run details. A green run gets announced with the manifest attached, so the release notes wrote themselves along the way. ## Human-in-Loop Highlight Run Pipeline pointed at the production pipeline is the one operation in this connector that reaches customers, and Update Pull Request can complete a merge into the branch that pipeline builds from. Neither runs on an agent's judgment alone. Before the release run, the agent posts to the release manager: "Release 2026.31 contains 18 commits and 6 completed pull requests, linked work items listed below. Two items carry open comments. Approve the production pipeline run on release/2026.31, or hold?" The manager approves or holds. The agent queues the run, polls the result, and reports back. Everything before the trigger pull is automated; the trigger pull is not. Agent processes routinely Detects exception requiring judgment Clear match Continues automatically Ambiguous Routes to human via preferred channel Human decides Agent resumes with decision ## Agent Capabilities 28 actions ### Projects and Teams 3 - **List Projects** Lists the team projects the token can access. Used to scope workflows to the right project. - **Get Project** Retrieves a project's description, state, and capabilities. - **List Teams** Lists the teams in a project. Used to resolve ownership before routing work. ### Work Items 7 - **Get Work Item** Retrieves a work item with all fields, relations, and links. Used to gather full context before commenting or updating. - **Get Work Items Batch** Retrieves up to 200 work items in one call. The bulk-fetch step behind sprint reports. - **Create Work Item** Creates a Bug, Task, User Story, Feature, Epic, or Issue in a project. The intake step that turns alerts and requests into tracked work. - **Update Work Item** Updates fields on an existing work item. Used to keep state, assignment, and iteration current as workflows progress. - **Delete Work Item** Sends a work item to the recycle bin, or permanently deletes it when Destroy is enabled. The Destroy path is gated on human approval. - **Add Comment to Work Item** Adds a comment to a work item's discussion. Used to thread new occurrences and agent findings onto the existing record. - **List Work Item Comments** Lists a work item's comments, most recent first. Used to check prior context before adding more. ### Queries 1 - **Run WIQL Query** Runs a Work Item Query Language statement and returns matching work item references. The search step behind dedup checks and every scheduled report. ### Repositories 5 - **List Repositories** Lists a project's Git repositories. - **Get Repository** Retrieves a repository's default branch, size, and clone URLs. - **List Branches** Lists a repository's branches. Used to verify a source branch exists before opening a pull request. - **List Commits** Lists commits newest first. The evidence step behind release manifests. - **Get File Content** Retrieves a file's text content at a path, optionally at a branch. Used to read configuration and changelogs inside workflows. ### Pull Requests 5 - **List Pull Requests** Lists pull requests filtered by status, target branch, and creator. Used to assemble what merged in a release window. - **Get Pull Request** Retrieves a pull request's title, status, reviewers with votes, and merge status. Used to check review state before any completion step. - **Create Pull Request** Creates a pull request from a source branch into a target branch. Used to open fix branches with the context pre-filled. - **Update Pull Request** Updates a pull request: retitle it, complete it, abandon it, or reactivate it. Completion into a protected branch runs only behind the human gate. - **Add Pull Request Comment** Adds a comment thread to a pull request. Used to annotate PRs with linked issues, test results, and agent findings. ### Pipelines and Builds 6 - **List Pipelines** Lists the pipelines defined in a project. - **Run Pipeline** Queues a pipeline run, optionally overriding branch, parameters, and variables. Production targets run only after a named person approves. - **Get Pipeline Run** Retrieves a run's state and result. The polling step that closes the loop after a queued run. - **List Builds** Lists builds filtered by definition, status, and result. Used for failure sweeps and build health reports. - **Get Build** Retrieves a build's status, result, source branch, and timing. - **Queue Build** Queues a classic build for a definition, optionally on a specific branch. ### Sprints 1 - **List Team Iterations** Lists a team's iterations, filterable to the current sprint. The anchor for every sprint-scoped query and report. ## Frequently Asked Questions ### What can FlowRunner do with Azure DevOps? FlowRunner agents can run List Projects, Get Project, and List Teams in Azure DevOps, plus 25 more actions. ### Does connecting Azure DevOps to FlowRunner require OAuth? No. Azure DevOps connects to FlowRunner with basic authentication (a username and password), no OAuth flow required. ### Can Azure DevOps trigger a FlowRunner workflow automatically? Azure DevOps doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger. **Work at Azure DevOps?** This integration exposes Azure DevOps to AI agents on every FlowRunner plan, including through MCP, at no cost to you. [See what FlowRunner offers integration partners](https://flowrunner.ai/integrations/partners), including how to keep this page current. --- Markdown version of https://flowrunner.ai/integrations/azure-devops. Site index: https://flowrunner.ai/llms.txt