In Azure DevOps, you can initially create a pull request as a draft if the changes are not yet ready for the normal review process. You can publish it later, abandon it if needed and then reactivate it afterwards. For teams using Azure Repos and Azure Pipelines, what matters most is how this status affects review, policies and builds.
A pull request is the request to bring changes from a source branch into a target branch, triggering review and branch policies in the process. This article addresses exactly that practical workflow question and focuses on Azure DevOps Services with Azure Repos. Azure DevOps Server is only of peripheral relevance here, because according to Microsoft several newer features are not available there, or not yet available.
When to open a draft pull request
A draft pull request fits typical day-to-day team situations: the technical direction is already clear, but the change is not yet mature enough for the normal review process. In other words, you want to make visible what you are working on without yet kicking off the team’s full review process.
In practice, this is useful in cases such as these:
- You want early feedback on the architecture or proposed solution.
- Interfaces, data models or API boundaries need to be aligned in advance.
- Parallel work within the team should remain visible so that changes do not overlap unnecessarily.
- The later review process should be prepared even though some points are still open.
- The current state of the work should remain traceable directly on the related work item.
This is particularly useful for tech leads when work in progress should be visible, but reviewers should not yet take on a formal review. For developers, draft status is often useful when known gaps are still open, for example around tests, tidying up commits or individual unresolved comments.
The distinction matters: a draft is not a replacement for a normal pull request. It is an intermediate stage before the actual release for review. As soon as you publish it, the pull request enters your team’s usual review flow.
In many teams, the pull request is also linked to a work item from Azure Boards. Microsoft lists checking for linked work items as a possible branch policy; however, it is switched off by default. Source: Microsoft Learn, “Branch policies overview” and “Branch policies”, accessed on 01.11.2026.
If you would like to refresh the workflow step by step, you can find it in the article read through the basic process step by step once again.
Publish, abandon, reactivate
What matters here is less the technical side than keeping statuses cleanly managed. By publishing, you turn a visible interim state into a pull request that is now deliberately entering your team’s normal review process. From that point on, it should be clear to everyone involved: discussion, yes, but no longer just for orientation, rather with completion in mind.
Abandoning makes sense if the business need no longer exists or the chosen solution is no longer being pursued. That way, you avoid outdated pull requests appearing in lists as if they were active work. For tech leads, this is especially helpful when several topics are running in parallel and priorities shift.
You can reactivate the same pull request if that exact change is to be continued and the existing history still fits. This is particularly worthwhile if context already exists, for example:
- questions about the implementation
- decisions on interfaces
- notes from early comments
- the connection to the discussion so far
In practice, it helps to add a brief note in the pull request explaining why you are publishing, abandoning or reopening it. A short sentence is often enough to make it clear later whether work was paused, discarded or resumed.
Separate from this is the question of how the change is ultimately merged. Draft or published status does not control your branch history. Microsoft describes “Limit merge types” as governance for history, not as a direct security control. You can find that classification in the article on merge strategies in Azure Repos.
What happens to policies and builds in drafts
For drafts, the key point is this: the status does not change the protection rules of the target branch. What matters are the branch policies configured there.
According to Microsoft Learn, Azure Repos supports, among other things, these policy types: minimum number of reviewers, linked work items, comment resolution, Limit merge types, build validation, status checks and automatically included reviewers. All of them are switched off by default. Source: Microsoft Learn, these policy types are described in “Branch policies overview”, accessed on 01.11.2026, as well as “Branch policies” and “Securely use Git pull requests and branch policies to protect your important branches”, accessed on 01.11.2026.
What matters is the difference between two mechanisms:
- Build validation starts a build or pipeline check for the pull request.
- Status checks are status messages on the pull request that can be set as required conditions.
For reviews, the details are often more important than the number alone. For reviewer policy, Microsoft mentions options such as whether authors may approve their own changes, whether the most recent pusher may not approve their own changes, and what happens to existing approvals when new pushes are made. Source: Microsoft Learn, “Branch policies”, accessed on 01.11.2026.
For important branches, Microsoft recommends the following as part of a baseline: grant permissions to bypass policies only very narrowly, require at least two reviewers, automatically include reviewers for sensitive paths, check linked work items, enable build validation and require comments to be resolved. Source: Microsoft Learn, for important branches Microsoft recommends “Securely use Git pull requests and branch policies to protect your important branches”, accessed on 01.11.2026.
If you use an AI-based review in Azure DevOps Services, you should look closely at the status: according to Microsoft, Copilot Code Review is in Public Preview, can start automatically via branch policy and always leaves a Comment review. This feedback does not satisfy a Required reviewer policy and does not block a merge. Preview features have no SLA and may change. Source: Microsoft Learn, “Sprint 279 Update”, “Review pull requests” and “Copilot code reviews”, accessed on 01.11.2026.
To stop reviews getting bogged down in formalities, often all it takes is a clear PR template.
Frequently asked questions
How can you use draft, published and completed meaningfully in the team process?
A simple distinction by intent is useful:
- Draft when you want to make the direction or open points visible
- Published when a normal review is wanted
- Abandoned when this route is no longer being pursued
That helps prevent drafts from quietly turning into a second task list. A pull request is not a substitute for a ticket, but the place for changes to the code and their review.
When does a draft become organisationally problematic?
Usually not technically, but in the workflow. It becomes critical when nobody knows any longer whether the current state is merely paused, no longer relevant from a business point of view or still active. At that point at the latest, a brief note in the pull request text or abandoning it is worthwhile.
If your organisation has requirements around traceability, internal controls or segregation of duties, that tends to affect the overall review and approval process rather than draft status itself. If you have questions about DORA, NIS2, data protection or co-determination, you should clarify them with legal advice or your data protection officer.
What role does the merge type play for draft pull requests?
Draft status does not answer that question. Merge type affects the history of the target branch. If your team later evaluates commit sequence, traceability or release documentation, you should make that decision consciously in the branch rules rather than only when completing the pull request.
Can you get directly from a work item to a reviewable pull request?
In Azure DevOps Services, this is not described in the Microsoft sources named here as a general standard feature for Azure Repos. Yet that is exactly where many teams find the practical gap between board, code, review and policies.
In that context, it is worth looking at the currently described state in Security and data, the planned commercial model in Packages and sign-up, the still empty section Measurements and results and changes in the public changelog. Polier is in development and, as of 01.11.2026, is not yet available.
Habits that keep your PR list tidy
Draft pull requests are most useful when your team cleanly separates three states: in progress, ready for review and discarded. Without that separation, the PR list quickly becomes confusing, even if everything has formally been set up correctly.
In day-to-day work, a few simple habits help:
- Open a draft with a recognisable purpose, not automatically for every small change. A draft should make a specific question or a clear interim state visible.
- Phrase the title so that status and intent are immediately clear. For example, it helps if it is obvious whether feedback is sought on design, API, data model or test approach.
- Keep the description brief but unambiguous. Open points should be visible so that reviewers know what to look at now and what is deliberately still unfinished.
- Abandon drafts you no longer need consistently rather than leaving them open for weeks. That keeps lists, filters and expectations within the team clean.
- Before publishing, check the overall coherence once more: does the linked work item fit, are comments categorised, is the test status understandable, and is the correct target branch selected?
- Use a PR template for recurring requirements. A template is a predefined text for the description and checklist so that important information does not have to be reinvented every time.
- Maintain the policy configuration for sensitive branches consciously. Informal team rules help in discussion, but they do not replace technical safeguards. Microsoft points out that the individual branch policies are disabled by default. Source: Microsoft Learn, “Branch policies overview”, accessed on 01.11.2026.
That way, a draft remains what it is meant to be: a clearly marked interim state, not a permanent holding area for undecided work.