Azure DevOps
Developer ToolsConnect 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.
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](/concepts/human-in-the-loop) moments, because shipped software cannot be quietly unshipped.
Without FlowRunner
With FlowRunner
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](/integrations/slack) gets a one-line summary with the work item link. Paired with [GitHub](/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 Capabilities
28 actionsProjects 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.
Start building with Azure DevOps
$100 in credits. No card required. Connect in minutes.