You use mandatory reviewers in Azure Repos properly by deliberately involving the people or groups who are needed from a subject-matter perspective and keeping that separate from who is allowed to push, merge and bypass rules. This ensures the pull request is reviewed in the right places without mixing up permissions and review obligations.
In Azure Repos, mandatory reviewers only work cleanly if you define the purpose of the rule in advance: is it about subject-matter review, protecting sensitive changes, or a controlled approval path on main branches? Branch policies apply to the target branch of a pull request and should therefore be planned from the protection needs of the target branch, not from the habits of individual teams.
For a starting point, this order is usually enough:
- identify critical target branches
- name the roles that must review
- define the boundaries of sensitive change areas
- keep exceptions to a minimum
Azure DevOps Services and Azure DevOps Server follow the same basic principle here. You should check the differences in detail later depending on the product state of your environment.
Mandatory reviewers versus minimum number of reviewers
The core difference is simple: “Require a minimum number of reviewers” requires a certain number of approving votes, but does not name any specific people. “Automatically included reviewers”, by contrast, automatically adds specific people or groups to a pull request. The two complement each other; they do not replace each other. Microsoft describes these policies on the branch policy pages and in the security guidance for repositories and pull requests, each accessed on 01.11.2026.
This has an important operational consequence: if you only set a minimum number, there is no guarantee that the responsible roles will actually be involved in the review when IAM, network, platform or pipeline files are changed. You may then formally have enough votes even though, in substance, the wrong people carried out the review.
The reviewer policy includes several detailed options that you should choose consciously:
- “Allow requestors to approve their own changes”
- “Prohibit the most recent pusher from approving their own changes”
- “Allow completion even if some reviewers vote to wait or reject”
- for new pushes, “Require at least one approval on the last iteration”
- and also resetting approvals or all reviewer votes after changes
An iteration is the state of a pull request after new commits or updates. These options in particular determine whether a review acts more as a formal hurdle or as a reliable approval path.
In “Secure repositories in Azure Repos and GitHub”, accessed on 01.11.2026, Microsoft lists, among other things, the following as a security baseline for main branches: at least two reviewers, linked work items, build validation, comment resolution and automatically added reviewers for sensitive paths.
The important point is how to classify this: such policies are governance decisions. They control approval paths, but they do not replace clean permissions at repository and branch level. Who is allowed to push directly or bypass rules is therefore a separate topic in its own right.
For larger organisations, the practical rule is: plan the minimum number and the mandatory roles together. Otherwise teams may comply with the rule on paper while, in practice, the right functions are not reviewing the change.
Automatically added reviewers with path filters
Path filters turn the reviewer rule into a responsibility tool. The “Automatically included reviewers” policy adds people or groups to a pull request only if, in addition to the target branch, certain paths are affected. Microsoft refers to this policy in “Branch policies overview” and “Branch policies”, each accessed on 01.11.2026.
Their practical value lies in clearly defined areas of responsibility. Not every change needs the same reviewers. This becomes especially relevant where a repository combines product code with central operational artefacts.
Path filters are typically suitable for:
- infrastructure definitions
- pipeline files
- directories related to roles, permissions or policies
- central templates and shared configuration
For the rule to work reliably, the folder structure must reflect those responsibilities as well. If sensitive files are spread across many locations, maintenance effort increases and the mapping becomes harder to follow. A path filter is technically precise, but organisationally it is only as good as the naming and filing conventions in the repository.
Operationally, this means: keep the paths narrowly defined, document exceptions sparingly and review the rules again after renames or reorganisations. A mapping that is too broad creates unnecessary reviews; one that is too narrow misses changes.
If you want to place the whole set of rules in context again, the branch policy framework helps. For larger environments, it is also relevant that, according to Microsoft Learn in “Branch policies”, accessed on 01.11.2026, policies can also be managed via “az repos policy” or through the API; you can find the technical framework for that in Pull requests via REST API.
Sensitive paths: infrastructure, authentication, pipelines
Sensitive paths in many repositories mainly fall into four areas:
- infrastructure definitions
- authentication and authorisation configuration
- build and release pipelines
- security-relevant templates and central configuration files
In these areas in particular, it should not just be “some” reviewers casting votes. Changes in these paths often affect not only a business function, but also permissions, deployment, use of secrets or the software supply chain. A small change to a pipeline or role logic can therefore have a wider impact than an ordinary change in product code.
At the same time, you should not define sensitive paths too broadly. If too many folders fall under the same reviewer rule, very many pull requests end up with the same teams. That increases review queues and often lowers signal quality, because reviewers increasingly see changes for which their specific responsibility is not actually needed.
For particularly critical directories, a combination of several protection mechanisms is often sensible: automatically added reviewers, minimum number of reviewers, build validation, linked work items and comment resolution. Microsoft Learn lists these policy types in “Branch policies overview” and “Secure repositories in Azure Repos and GitHub”, each accessed on 01.11.2026. If you want to add status checks as well, you can find the context in our article on using PR status as a policy.
You should consider the “Limit merge types” policy separately from this: it controls history and, according to Microsoft in “Secure repositories in Azure Repos and GitHub”, accessed on 01.11.2026, is not a direct security mechanism. If your audit model depends on the exact commit sequence, Microsoft may recommend merge-commit strategies instead of squash. We have summarised the differences in a separate overview of merge strategies.
Operationally, one point matters in particular: review these sensitive paths again after repository reorganisations. Folder moves, new directories or renamed templates can otherwise quietly slip out of your rules.
Pitfalls: groups, unavailability, self-approval
The operating rule behind it is often harder than the technology. If you enter groups as mandatory reviewers, it still has to be clear internally who accepts reviews, who may act as cover and when matters are escalated. Otherwise the right group appears in the pull request, but nobody feels responsible.
Typical weak points are:
- groups defined too broadly
- memberships not maintained after team changes
- no cover during holidays or on-call duty
- tacit exceptions under time pressure
Especially for protected target branches, you should clarify these questions in advance rather than only when a pull request grinds to a halt.
The approval options in the reviewer policy are also delicate. In “Branch policies” (accessed on 01.11.2026), Microsoft lists, among other things, “Allow requestors to approve their own changes”, “Prohibit the most recent pusher from approving their own changes” and, for new pushes, “Require at least one approval on the last iteration”. An iteration is the state of a pull request after further commits or updates. If approvals after new pushes are not handled appropriately, an old “Approve” can easily remain attached to a state that has since changed.
For day-to-day work, the key question is therefore not whether a policy exists, but whether it fits your approval model:
- Should the author count as a valid vote at all?
- Should the last push trigger a fresh independent review?
- What happens if a mandatory reviewer is unavailable?
Many of these issues are not solved with yet another exception, but with a clear PR template setting out responsibilities.
Frequently asked questions
Are mandatory reviewers alone enough for a sound approval path?
Not always. Mandatory reviewers ensure that certain people or groups appear in the pull request. But whether the approval path works in day-to-day practice often depends on adjacent rules.
Three points matter most:
- Who is allowed to bypass policies?
- Which votes remain valid after new pushes?
- Which target branches are protected at all?
Especially on main branches, it is otherwise easy to end up with a formal review process that is still bypassed in special cases. In “Secure repositories in Azure Repos and GitHub”, accessed on 01.11.2026, Microsoft recommends for main, among other things, a small admin group for the permissions to bypass policies when completing pull requests and when pushing.
When do mandatory reviewers not help, even though they are configured correctly?
A typical case is pull requests with merge conflicts. In that situation, the bottleneck is not the reviewer rule but the technical state of the pull request. A merge conflict means that the source and target branch change the same locations differently and Git cannot merge them automatically.
If reviews stall because of this, you should resolve the conflict first and only then think about additional review rules. On the practical side, a clean process for resolving merge conflicts is often helpful.
What should you also check for AI review in Azure Repos?
Alongside its role in the approval path, also look at the operating framework. In “Copilot code reviews”, accessed on 01.11.2026, Microsoft Learn describes limitations such as active pull requests only, no merge conflicts, repository size up to 10 GB and upper limits for changed files and changes. In “Copilot code reviews FAQ”, accessed on 01.11.2026, Microsoft also notes that data residency is not tied to the data residency boundaries of the Azure DevOps organisation.
For data protection, DORA, NIS2 and co-determination, this is a question to assess, not a blanket statement. Clarify the planned use with your legal department, data protection officer or works council.
What needs separate attention in Azure DevOps Server?
In server environments, you should not assume the same feature state as in Azure DevOps Services. Based on the pages checked on 24.10.2026 and reviewed again on 01.11.2026, Microsoft does not document AI review for Azure DevOps Server.
If your organisation is fundamentally reassessing the platform, the broader decision between operating models and tool paths is more helpful than a single reviewer rule on its own. For that, the overview of Azure Repos or GitHub is a better fit.
If you also want to follow how a planned coding agent is intended to work with existing branch policies and PR status: Polier is in development and is not yet available as of 01.11.2026; you can find the current status in the public changelog.
Next step
Do not set up mandatory reviewers as an isolated measure, but as a verifiable rule for target branches requiring particular protection. In the end, what matters is less the number of tick boxes than a clear allocation: who must review from a subject-matter perspective, and on which paths should that reliably apply?
Finally, a look ahead: if you want to follow how Polier is intended to work with existing policies, you can find the planned position on security and data, on subscription and access and later on measured results from real runs. Polier is in development and is not available as of 01.11.2026.