Azure DevOps: why an approval does not count toward the minimum number of reviewers
The branch policy Require a minimum number of reviewers counts approvals, but not every approval. A few options of the policy decide which votes count, and a push to the source branch can take approvals away. When a pull request shows enough approvals and the policy still is not met, one of these options is usually the reason.
The options
From Microsoft's page Set and manage branch policies (updated July 2026):
- Allow requestors to approve their own changes: without it, the creator of the pull request can still vote Approve, but the vote does not count toward the minimum.
- Prohibit the most recent pusher from approving their own changes: the vote of whoever pushed last to the source branch does not count, even where they could otherwise approve their own changes. Microsoft gives it as a way to enforce segregation of duties.
- Allow completion even if some reviewers vote to wait or reject: without it, one Wait for author or Reject vote keeps the pull request from completing. With it, the minimum number of approvals is still needed.
- When new changes are pushed, one of:
- Require at least one approval on every iteration: a user's approval does not count for an earlier iteration that the same user pushed and nobody approved, so another user has to approve the last one (Azure DevOps Server 2022.1 and later).
- Require at least one approval on the last iteration: at least one approval on the latest push of the source branch.
- Reset all approval votes (does not reset votes to reject or wait): a push removes the approvals.
- Reset all code reviewer votes: a push removes every vote, approvals, rejects and waits alike.
Named reviewers are a separate policy, Automatically included reviewers: when it is set to Required, each person added must approve, and at least one member of each group, whatever the minimum count says. It has its own Allow requestors to approve their own changes.
"At least 1 reviewer besides most recent pusher must approve the most recent iteration"
A policy that is not met shows on the pull request as one line, and people search for lines like this one, or "At least one reviewer must approve the most recent iteration". Each part of the line is one of the options above:
- "At least 1 reviewer": the minimum number of reviewers.
- "besides most recent pusher": Prohibit the most recent pusher from approving their own changes is on. Whoever pushed last to the source branch, often the author after a fix or a reviewer who pushed one, cannot give the approval that counts.
- "the most recent iteration": the policy wants an approval on the latest push (Require at least one approval on the last iteration, or on every iteration). Each push to the source branch is a new iteration, so an approval given before the latest push does not meet it.
Put together: after the latest push, someone other than the person who made it approves. If nobody else can, a user with the repository permission Bypass policies when completing pull requests can override the policy (explicit override to bypass policies).
Common cases
- You opened the pull request and approved it. Your vote counts only if the policy allows requestors to approve their own changes.
- You pushed a fix to a colleague's pull request, then approved it. With Prohibit the most recent pusher, your approval stops counting: another reviewer has to approve.
- Approvals disappeared after a push. The policy resets approval votes, or all votes, when the source branch changes: the reviewers approve the new commits again.
- Enough approvals, still not met. Look for an approval that does not count (the creator's, the last pusher's), for a policy that needs one on the latest push, or for a Reject or Wait for author vote when completion with them is not allowed.
- The count is met, but completing is refused. Another policy has not passed: required reviewers, a build, comment resolution or linked work items. See explicit override to bypass policies.
In a script
Azure CLI sets the policy with az repos policy approver-count create or update; its --creator-vote-counts, --allow-downvotes and --reset-on-source-push are the options above. To see why a pull request's policy is not met, the policy evaluations of the pull request (GET {project}/_apis/policy/evaluations?artifactId=…, a preview API) give each policy's status and its configuration; for this policy, the settings include minimumApproverCount, creatorVoteCounts, blockLastPusherVote, requireVoteOnLastIteration, requireVoteOnEachIteration and allowDownvotes.
Azure DevOps pull requests in IntelliJ IDEA and Rider
Azure DevOps Pull Requests, a plugin by Lesstep for JetBrains IDEs 2024.1 or later and Android Studio, lists the pull requests that wait for your review in an IDE tool window, on Azure DevOps Services and on Azure DevOps Server. It shows the branch policies of a pull request in words, with their state: for this one, for example, "At least 2 approval(s); the author's own vote does not count; the most recent pusher's approval does not count; approvals must be on the latest push", and builds, comment resolution and work items next to it. From version 1.0.44, an approval is not sent when the source branch got new commits after you opened the pull request, since an approval would count for them too. The review inbox and the branch policies are free; voting, commenting, completing and creating are Pro, with a 30-day trial.
Get it on JetBrains Marketplace
Azure DevOps is a trademark of Microsoft Corporation; IntelliJ IDEA and Rider are trademarks of JetBrains s.r.o. This page is not affiliated with or endorsed by Microsoft or JetBrains.
More: the five votes · required reviewers and path filters · explicit override to bypass policies · TF402455: pushes to this branch are not permitted · Azure DevOps pull request plugins for IntelliJ IDEA, compared · 日本語