You can reset reviewer votes on pushes in Azure Repos via the reviewer policy in the Branch Policies in Azure DevOps. Depending on the setting, there are three approaches for new pushes: keep votes in place, require at least one approval on the last iteration, or reset votes.
An iteration is the state of a pull request after a new push to the source branch. In other words, it means the latest version of the proposed changes.
This article covers Azure Repos in Azure DevOps. For Azure DevOps Services, the options are documented in Microsoft Learn; for Azure DevOps Server, the exact scope depends on the version. Sources: Microsoft Learn, “Branch policies” and “Branch policies overview”, accessed on 01.11.2026.
Why approvals can become outdated
In practical terms, an approval always applies to a specific state of the pull request. If there is then a new push to the source branch, that exact state may have changed. In that case, it is no longer certain that the earlier approval still carries the same weight.
This is not limited to major rewrites. Even small changes can make another look sensible, for example:
- review comments that have been implemented,
- a fix added afterwards,
- newly added commits,
- changes made while resolving merge conflicts.
For protected branches, this is a governance issue: who saw which version, and which state was actually approved? Especially where several roles are involved, older votes should not automatically be treated as equally reliable after a push.
There is also the wider context of the other branch policies. According to Microsoft Learn, these include the minimum number of reviewers, linked work items, comment resolution, allowed merge types, build validation, status checks and automatically included reviewers; all are disabled by default. Sources: Microsoft Learn, “Branch policies overview” and “Branch policies”, accessed on 01.11.2026.
For sensitive paths, automatically included reviewers can also be important. For main, Microsoft also recommends at least two reviewers, build validation, comment resolution, linked work items and tightly controlled policy bypass permissions, among other things. Source: Microsoft Learn, “Secure Azure Repos pull requests”, accessed on 01.11.2026.
The options for new pushes
What matters is the reviewer policy of the target branch. That is where you define what happens to existing votes after a further push to the source branch.
In “Branch policies” and “Branch policies overview”, Microsoft documents three relevant behaviours for new pushes, accessed on 01.11.2026:
- “Require at least one approval on the last iteration”
- “Reset all approval votes”
- “Reset all code reviewer votes”
The difference between them is clear.
“Require at least one approval on the last iteration” leaves the existing vote history in the pull request intact, but requires at least one fresh approval for the latest state. The history therefore remains readable, without older approvals being enough on their own for the current state.
“Reset all approval votes” resets the positive approvals when there is a new push. Earlier approvals then no longer count for the updated version.
“Reset all code reviewer votes” goes further. Here, reviewer votes are reset across the board. If you want to treat a push as a clear restart of the formal assessment, this is the stricter option.
For day-to-day operations, a simple way to think about it is:
- last iteration: a fresh look at the current state, while earlier votes remain visible
- approval reset: positive approvals must be given again after a push
- full vote reset: the review status is rolled back more broadly
This setting only controls how votes are handled after new pushes. It does not replace questions of push, merge and bypass permissions, nor rules for unresolved discussions; that is what the policy for comment resolution on open threads is for.
Important for Azure DevOps Server: the exact choice depends on the version. Microsoft documents “Require at least one approval on the last iteration” for Azure DevOps Server 2022.1 and later; there is also an additional variant, “on every iteration”. Sources: Microsoft Learn, “Branch policies” and “Branch policies overview”, accessed on 01.11.2026.
Approval on the last iteration
This option is especially useful if you want a renewed confirmation of the current state after a push without making the previous review history unreadable. It shifts the focus to the latest version of the pull request rather than formally invalidating every earlier contribution.
It is particularly suitable in situations like these:
- after a small fix based on review comments,
- after an adjustment that makes the build green again,
- after editorial or structural changes,
- where the pull request is deliberately refined in several small steps.
For governance, it is important to understand what this option does not do: it does not force all previously involved people to review again. If the same specialist role should always take another look at certain files or directories, you are more likely to need appropriately configured automatically included reviewers for that. Source: Microsoft Learn, “Secure Azure Repos pull requests”, accessed on 01.11.2026.
Likewise, this does not affect the question of open discussions. Unresolved threads are not automatically dealt with by this setting. In practice, a concise PR template with a checklist often helps here, so it is visible before completion what really still needs to be done.
In short: this option makes sense if you want a fresh look at the last iteration, but do not want to treat every new push as a complete restart of the review.
Effects on the workflow
The setting for new pushes mainly affects your approval chain. More important than the individual pull request is the question of when a branch is regarded as sufficiently reviewed again after a change.
In practice, three points are usually important:
- who is still able to give an effective approval after a push,
- which checks must succeed in addition to reviews,
- and whether your team tends to expect small touch-ups or longer PR series.
That is why, especially in platform teams, it is worth looking at the order of policies. If a human approval is required again after a push, but build validation is still running or a status check is still pending, the completion of a PR is often pushed organisationally to the end of all technical checks. A status check is an external check status that Azure Repos can evaluate as another mandatory condition for completion. Source: Microsoft Learn, “Branch policies overview”, accessed on 01.11.2026.
Regardless of that, the merge type remains a separate decision. Microsoft classifies “Limit merge types” as a way of controlling history, not as a direct security mechanism. If your traceability depends on the exact sequence of commits, you should review the choice of merge method carefully; the overview of merge types and history can help with that. Sources: Microsoft Learn, “Branch policies overview” and “Sprint 279 Update”, accessed on 01.11.2026.
The direction of travel of your platform also plays into this. Microsoft describes Enterprise Live Migrations as a way to move repositories to another Git platform while continuing to use Boards and Pipelines. For architecture and standardisation questions, what matters is therefore often not just the individual reviewer option, but the longer-term role of Azure Repos; the article on decision criteria for choosing a platform fits that context. Source: Microsoft Learn, “Sprint 279 Update”, accessed on 01.11.2026.
Common operational questions
Is the last iteration enough for sensitive branches, or should votes be reset completely?
That depends mainly on how you assess a new push in practical terms. If follow-up changes are usually small and you want the review history to remain visible, tying approval to the last iteration is often enough. If a push materially changes the content, a full reset is usually the clearer rule.
A simple distinction can help:
- a small correction after review,
- an additional commit with new risk,
- conflict resolution involving changed code,
- a change in areas with a tightly controlled approval chain.
The more a push changes the basis for assessment, the more likely a stricter reset of votes is to fit.
Does this apply in the same way to Azure DevOps Server as to Azure DevOps Services?
Not automatically. Microsoft documents the options for Azure DevOps Services in Learn; for Azure DevOps Server, the exact scope depends on the version. In practice, that means: do not carry a policy over between Services and Server without checking it.
Before standardising, check in particular:
- which option your Server version actually provides,
- whether your teams need the same review workflows,
- whether documentation and screenshots match the version in use.
Especially in mixed environments, that avoids misunderstandings around approvals shortly before completion.
Do automated checks replace the question of older reviewer votes?
No. Technical checks and reviewer votes answer different questions. A build may succeed even though, after a new push, nobody has reviewed the current state again from a subject-matter point of view. Conversely, a fresh approval does not replace build validation or a status check.
In practice, what usually matters is the combination of:
- human approval for the current state,
- mandatory technical checks,
- tightly controlled exceptions for bypassing policies.
If you also need to assess such rules from data protection, DORA, NIS2 or co-determination perspectives, you should review that with legal advice or with your data protection officer, as applicable.
Where can we see the status of planned features without inferring availability from it?
If that matters for your platform planning: the public changelog shows the development status. The page on security and data explains what currently applies to security and data and what does not yet apply. The provisional packages and sign-up page sets out the planned sign-up and packages. Whether real measured results are already available can be seen on the page on measured results.
Next step
Do not set the option in isolation, but as part of your approval logic. What matters is whether, in your organisation, a new push is treated more as an addendum or as a new review baseline.
Four guiding questions can help with the decision:
- What would be the consequences of an outdated approval on this branch?
- How much do pull requests typically change after the first review?
- Do certain roles need to see the latest state again?
- How clearly is it documented for teams when a vote should still count after a push?
A short practical test using typical PR patterns from your own environment is also worthwhile.
If your planning also includes future agents for Azure DevOps Services: as of 01.11.2026, Polier is in development and not yet available.