An Azure DevOps pull request dashboard that shows whose move it is.
Pull requests from your Azure DevOps project, sorted into Needs you, Waiting on others and the ones that can wait. It is a desktop app, and it checks which of your branch policies are actually required before calling anything blocked.
Not every red policy on Azure DevOps blocks a merge.
Branch policies can be required or optional, and status checks are reported against a specific push. If a tool reads every red mark as a blocker, you end up chasing optional checks that your team decided not to enforce.
Required and optional are kept apart
PR Flow reads which policies actually block the merge. An optional check that fails is still shown, worded as “not required to merge”. An approved pull request with only optional failures can still show as Merge ready on the board. When Azure cannot say whether a check is required, PR Flow counts it as blocking.
A failure from an earlier push
A status check that failed on an earlier iteration no longer counts against the current one. A status that Azure attaches to the whole pull request, rather than to one push, is always treated as current. And a policy Azure reports as rejected keeps blocking until Azure stops reporting it.
A merge conflict waits on the author
Resolving a merge conflict is the author's job, so a teammate's conflicted pull request moves to Waiting on others until they fix it. If you owe someone a reply in one of its threads, it stays in Needs you anyway.
Replies you owe, without the bots
Threads where someone answered you count as yours to act on. Recognised automated reports stay out of that count.
Setting it up, and reviewing from it.
What Settings asks for
Your organization URL, the project and a personal access token. The token is encrypted with your operating system's keychain, and PR Flow refuses to save it if that encryption is not available. Requests to Azure DevOps go from your machine.
- Code (Read) and Pull Request Threads (Read & Write) to read and review
- Identity (Read) so teammate search can find people
- The connection is tested before it is reported as connected
Staging, then submitting
Read the diff, expand the code around a hunk, and stage inline comments, replies and comments on a whole file. On submit, your vote is cast first, then each comment and the summary are posted one at a time, because that is how Azure takes them. If one fails, the ones before it have already posted, and the finish sheet lists what did not.
- Staged comments stay local until you submit
- Resolving or reopening a thread applies straight away
- Every write is recorded in a local audit log you own
Stacks, local checkout and AI findings.
Stacks, labelled as a guess
Azure DevOps has no stack information. When one pull request targets another's source branch and the chain is unambiguous, PR Flow shows it as a stack and marks it as inferred.
Check out the pull request locally
If you have mapped the repository to a local clone, one confirmed action fetches the pull request and checks out a local branch for it. It refuses to touch uncommitted work and never force-updates a branch.
Optional AI review
With agents enabled, findings run through your own AI provider. If the code a finding quotes is not on the line it names, the finding loses the line and becomes a comment on the file. You decide what gets posted.
See every provider on the pull request dashboard, or how the ordering works on the review queue page.
Azure DevOps specifics.
What do I need to connect Azure DevOps?
Can it watch several organizations or projects?
Which votes can I cast from PR Flow?
Does it work with Azure DevOps Server on our own host?
We use Azure DevOps for some repos and GitHub for others.
Keep reading
Pull request dashboard
One ranked queue for pull requests spread across repos and providers.
Pull request review queue
How PR Flow decides which review needs you next, and why that beats a feed.
Stacked pull requests
Stacks as one ordered journey — position markers, a map, and layer-by-layer review.
Local AI code review
AI review on your own provider — a CLI, a local model, or your gateway.
From the blog
Who Owns the Next Move on a Pull Request?
Open, review requested and approved don't answer who has to act next. A plain event-driven model for pull request ownership, and where it stops helping.
How to Review Stacked Pull Requests When the Base Moves
In a stack, an upper layer's diff can stay the same while the code under it changes. What to recheck when a lower layer gets fixes, main moves, or the bottom merges.
Try it on your own Azure DevOps project.
Completing a pull request is always your click, after PR Flow checks its policies. Try PR Flow free for 7 days; a one-time licence keeps it after the trial.