Using PR status in Azure DevOps as a policy means integrating external check results as a status check into the branch policies of a target branch. Only when an expected status is configured there as required can a pull request be completed only with that successful status; statuses set as optional merely provide information.
A pull request status is a check signal that an external service reports to a pull request. It sits alongside review votes and build validation and serves its own distinct purpose.
This distinction is especially important in practice:
- Status check: result of a connected external check
- Reviewer vote: human assessment during review
- Build validation: build or pipeline check before completion
This article explains when status checks make sense as a policy, how they differ from other policies and what you should bear in mind when using them in Azure DevOps. It is based on Microsoft Learn, "Branch policies overview", "Branch policies" and "Secure repositories with pull requests", each consulted on 01/11/2026.
What a pull request status is
A pull request status is a machine-readable state that an external checking service reports to a pull request. Azure Repos can then take that reported state into account when deciding whether a pull request may be completed.
A branch policy is a rule on the target branch that determines which conditions must be met before a pull request can be completed.
The distinction from other mechanisms is important: a status is not a reviewer vote, nor is it build validation. In Azure Repos, these controls sit alongside one another and fulfil different roles.
According to Microsoft Learn, Azure Repos includes, among others, these branch policies:
- minimum number of reviewers
- linked work items
- comment resolution
- allowed merge types
- build validation
- status checks
- automatically included reviewers
All of these policies are switched off by default (Microsoft Learn, available branch policies and branch policy settings, consulted on 01/11/2026).
In practice, this means status checks are particularly useful where the actual check takes place outside the built-in pull request logic, for example in security, licensing or external review systems. The pull request then becomes the shared control point for several checking steps.
If you want to manage policies technically, Microsoft Learn says you can set them via the REST API or using the commands around "az repos policy" (Microsoft Learn, policy management, consulted on 01/11/2026). If you want to understand the technical side of the integration, you can then read the article on Service Hooks for pull requests.
The "Status Check" branch policy: required or optional
What matters is not the reported status on its own, but how it is classified in the branch policy of the target branch. When set as required, it turns an external check result into a completion condition. When set as optional, it remains visible without blocking completion.
A simple distinction helps with operational decisions:
- required if an external checking step must reliably be present before completion
- optional if the status is only meant to provide additional context
But that only describes part of the protection profile. In its security baseline for protected branches, consulted on 01/11/2026, Microsoft additionally recommends tightly restricting permissions to bypass policies and push directly, requiring at least two reviewers, covering sensitive paths with automatically included reviewers, checking linked work items, using build validation and insisting on resolved comments. A status check complements these measures, but does not replace them.
Separate from that is the question of how you want your history to look. According to Microsoft Learn, the "Limit merge types" setting controls only the merge form and is not a direct security mechanism. On the page "Secure repositories with pull requests", consulted on 01/11/2026, Microsoft also notes that if your audit model needs the exact commit sequence, merge-commit strategies are a better fit than squash.
In practice, that means: first define permissions, reviews, builds and work item requirements properly, then use status checks selectively where an external finding should genuinely serve as a gate. For permissions around exceptions and direct access, the article on permissions and policy bypass is also relevant.
Status names, category and resetting on new iterations
For a policy to work reliably, statuses in your organisation should be named consistently and assigned to a clear source. If teams cannot clearly tell which external check sits behind a status, a gate quickly turns into a hard-to-follow special case.
A simple up-front definition is therefore useful:
- which statuses are mandatory
- what those statuses are called
- which service may set them
- when a status is considered outdated
- whether a new check should run automatically after changes
An iteration is the state of a pull request after a new push to the source branch.
That point matters in day-to-day work: each new iteration changes the basis for assessment. Organisationally, you should therefore clarify whether an external check must run again after every push and update its status. This is particularly obvious when the check depends on the specific diff; in that case it also helps to look at the lifecycle of draft pull requests.
According to Microsoft Learn, "Branch policies", consulted on 01/11/2026, reviewer policies in Azure Repos include options such as "Require at least one approval on the last iteration", "Reset all approval votes" and "Reset all code reviewer votes". On Azure DevOps Server 2022.1 and later, requirements on every iteration are added.
The distinction is important: these reset options affect reviewer votes, not automatically every externally set status. That is precisely why you should explicitly plan the re-run behaviour of the connected check rather than silently assuming it.
Typical uses: security scans, licence checks, review tools
Status checks are particularly suitable for checks whose result does not arise from a human review, but should still be visible and evaluable before a pull request is completed. Typical cases are:
- security scans
- licence or policy checks
- external analysis and review services
- organisation-specific approval signals
What matters here is less the category than the operational question: which external check should really be allowed to block completion, and which should only provide guidance?
A current reference point in Azure DevOps Services is Microsoft's Copilot code review in Azure Repos. According to Microsoft Learn, "Azure DevOps Sprint 279 Update" and "Copilot code reviews", consulted on 01/11/2026, the feature is in Public Preview, can be enabled at organisation, project or repository level, runs on a Managed DevOps Pool, supports Custom Instructions and can be triggered automatically via branch policies; Sprint 280 added the effort levels Lite and Balanced. For classifying the product line, the article on whether to choose Azure Repos or GitHub is helpful.
For policy use, however, a different boundary matters more: according to Microsoft Learn, "Review pull requests" and "Copilot code reviews", consulted on 01/11/2026, Copilot code review always leaves a Comment Review. That does not satisfy a Required Reviewer policy and does not by itself block the merge.
There are also documented usage limits: only active pull requests without merge conflicts, repository size up to 10 GB, up to 100 changed files and 100 changes, plus limits for simultaneous reviews. If you are assessing this for your portfolio, it often helps simply to look at the size of a pull request.
For external checks, the data path is part of the operational decision. In "Copilot code reviews FAQ", consulted on 01/11/2026, Microsoft explicitly mentions differing data residency boundaries. You should therefore review questions around data protection, DORA, NIS2 and co-determination with your legal department, data protection officer or works council; for your own documentation, a clear security and data overview is helpful.
Frequently asked questions
How can you tell whether a status is robust enough for use as a policy?
Pay less attention to the name of the signal than to how it comes into being. Operationally, what matters is whether it is clear which service sets the status, which state of the pull request it refers to and how a new run is triggered. If you want to inspect the technical chain, it often helps to look at the REST page for pull requests.
How do you document status rules so that teams can apply them in day-to-day work?
A short rule description where your team already looks up the pull request workflow is practical. The following points are especially useful:
- purpose of the status
- responsible source
- meaning of success, warning or error
- handling of new commits
- intended exception cases
If you document the workflow internally, you can link this neatly with your own PR process.
What matters for work items when status checks are part of the process?
As soon as a pull request is part of a governed change path, the link to the work item should be unambiguous. Otherwise an external finding may remain visible, but be hard to interpret in business terms. For many teams, it is therefore helpful to plan the status logic together with linking work items and pull requests.
What questions should you ask up front about data protection, DORA, NIS2 and the works council?
It makes sense to clarify four points early on:
- which content leaves the service
- where processing may take place
- which logs are created
- whether co-determination issues are affected
These are not merely settings in the tool. Discuss such points with your legal department, your data protection officer and, where appropriate, with the works council.
Where can you find information about a future product approach?
If you would like to keep track of the status of a future approach, you can find planned changes in the public changelog. Preliminary details on planned billing are on the pricing page, and the proof page is the place for later measurements from real-world operation. The closing section provides the one-off classification of this.
Next step
For critical target branches, first define a small, verifiable target state. What matters is not the number of rules, but that each rule has a clear purpose and remains understandable in operation.
Work with a short checklist:
- Which statuses are just informational, and which are gates?
- Who is allowed to provide each status?
- When is a status functionally outdated after new commits?
- What exceptions, if any, are actually intended?
You should plan separately for Azure DevOps Server. The policy pattern is transferable, but Microsoft's current AI features in this environment are not readily available; the options for Azure DevOps Services and Server currently differ significantly (Microsoft Learn, "Enterprise Live Migrations overview" and lifecycle pages, checked on 24/10/2026, partly consulted on 01/11/2026).
If you want to follow a future product approach for Azure DevOps Services: as of 01/11/2026, Polier is in development and not yet available.