How to fix TF401027: You need to resolve policy violations before completing this pull request in Git

GitBEGINNERMEDIUMUpdated Dec 6, 2025· 159 views

This Azure DevOps error occurs when you try to complete a pull request that hasn't met all the required branch policies. You'll need to satisfy the policy requirements such as reviewer approvals, successful builds, linked work items, or resolved comments before the PR can be merged.

Quick fix

Fixes TF401027

# Send a reminder via Azure CLI
az repos pr reviewer add --id <PR_ID> --reviewers <email@domain.com>
  1. Identify which policies are blocking completion
  2. Get required reviewer approvals
  3. Fix failing build validation
  4. Link required work items
git — error
# Send a reminder via Azure CLI
az repos pr reviewer add --id <PR_ID> --reviewers <email@domain.com>
TF401027: You need to resolve policy violations before completing this pull request

What this error means

The error "TF401027: You need to resolve policy violations before completing this pull request" appears in Azure DevOps (formerly VSTS/TFS) when you attempt to complete or merge a pull request that hasn't satisfied all the configured branch policies. Azure DevOps branch policies are rules that protect important branches like `main` or `develop`. When policies are set on a target branch, all pull requests targeting that branch must meet every policy requirement before completion is allowed. The TF401027 error is the system's way of telling you that one or more policies are blocking the merge. This isn't necessarily an error with your code—it's the policy enforcement system working as intended. The specific violations could range from missing reviewer approvals, failing build validations, unlinked work items, to unresolved PR comments. The error ensures that code quality and compliance standards are maintained before changes reach protected branches.

Typical symptoms

  • Cannot click 'Complete' button on pull request—it's disabled or shows warning
  • Error message 'TF401027: You need to resolve policy violations' displayed
  • Pull request shows 'Not all policies have been met' status
  • Build validation status shows 'Failed' or 'Waiting'
  • Minimum reviewer count not reached
  • Required reviewers haven't approved yet
  • Work item linking policy shows as not satisfied
  • Comment resolution policy indicates unresolved threads
  • Auto-complete is queued but PR won't merge
  • CI/CD pipeline blocked waiting for PR completion

Common causes

  1. Required number of reviewer approvals not obtained
  2. Mandatory build validation pipeline failed or not run
  3. No work item linked to the pull request when required
  4. Active PR comments not marked as resolved
  5. Required specific reviewers haven't approved
  6. External status checks failing or pending
  7. Merge strategy not allowed by branch policy
  8. Branch is out of date with target branch when freshness required
  9. Check-in notes or policies from inherited project settings
  10. User lacks 'Bypass policies' permission when trying to override

How to fix "TF401027: You need to resolve policy violations before completing this pull request"

1Identify which policies are blocking completion

First, determine exactly which policies haven't been satisfied:

1. Navigate to your pull request in Azure DevOps
2. Look at the Policies section on the PR overview page
3. Each policy shows a status icon:
- Green checkmark: Policy satisfied
- Red X: Policy violated/failed
- Yellow clock: Policy waiting/pending
4. Click on any failing policy to see details

Common policy types you'll see:
- Minimum number of reviewers: Shows current approval count vs required
- Build validation: Shows build status (passed/failed/pending)
- Work items: Shows whether work items are linked
- Comment resolution: Shows unresolved comment threads
- Required reviewers: Lists specific people who must approve

Note the specific violations—you'll address each one in the following steps.

2Get required reviewer approvals

If the minimum reviewer policy isn't satisfied:

Request reviews from team members:
1. On the PR page, click Reviewers in the right panel
2. Add team members who can review your changes
3. Optionally add a message explaining what to review
4. Wait for reviewers to approve

Reviewer options:
- Approve: Counts toward minimum reviewers
- Approve with suggestions: Still counts as approval
- Wait for author: Doesn't count until author addresses feedback
- Reject: Blocks completion (reviewer must change vote)

If reviews are stalling:

bash
# Send a reminder via Azure CLI
az repos pr reviewer add --id <PR_ID> --reviewers <email@domain.com>

Tips:
- Check if your organization has auto-assigned reviewers
- Some teams require specific code owners to approve
- A single rejection may block completion depending on policy settings

3Fix failing build validation

If build validation is failing:

Check the build status:
1. Click on the failing build in the Policies section
2. Review the build logs to identify the failure
3. Common failures include:
- Compilation errors
- Unit test failures
- Code coverage below threshold
- Linting/static analysis issues

Fix the issues and push:

bash
# Make necessary fixes locally
git add .
git commit -m "Fix build failures"
git push origin <your-branch>

The build will automatically re-run when you push new commits.

If the build is stuck or hasn't run:

bash
# Trigger a new build via Azure CLI
az pipelines run --name "<pipeline-name>" --branch <your-branch>

# Or re-queue build validation from the PR
# Click "Re-run" next to the build policy

If the build passes locally but fails in Azure DevOps:
- Check environment differences (Node version, OS, etc.)
- Verify all dependencies are committed or in package manager
- Look for flaky tests that pass intermittently

4Link required work items

If work item linking is required:

Link from the PR interface:
1. On the PR page, find the Work items section
2. Click Link work item or the + button
3. Search for the work item by ID or title
4. Select the appropriate link type (usually "Resolves" or "Related")

Link using commit messages:
Include work item IDs in your commits:

bash
# Azure DevOps recognizes these patterns
git commit -m "Fix authentication bug #1234"
git commit -m "Implement feature AB#5678"
git commit -m "Resolves: #1234"

Link via Azure CLI:

bash
# Link a work item to your PR
az repos pr work-item add --id <PR_ID> --work-items <WORK_ITEM_ID>

If no relevant work item exists:
- Create a new work item (Bug, Task, or User Story)
- Ask your project manager which work item to link
- Check if your team has a backlog item for this work

5Resolve all PR comments

If comment resolution is required:

Find unresolved comments:
1. Go to the Files tab in your PR
2. Look for comment indicators on changed lines
3. Or click Comments to see all threads

Resolve comments:
- Reply and resolve: Address the feedback, then click "Resolve"
- Won't fix: If you disagree, explain why and resolve
- Ask reviewer to resolve: Some teams require the commenter to resolve

Best practices:

text
When addressing feedback:
1. Make the requested code change
2. Push the commit
3. Reply to the comment with what you changed
4. Click "Resolve" on the thread

Bulk resolve (use carefully):
If there are many resolved discussions that weren't marked:
- Use the "Resolve all" option if available
- Or go through each thread systematically

Note: Active/unresolved comments are different from "Won't fix" comments. Even "Won't fix" should be marked as resolved with an explanation.

6Address required reviewer approvals

Some policies require specific people or groups to approve:

Identify required reviewers:
1. Check the Required reviewers policy in the PR
2. See which specific reviewers haven't approved yet
3. These might be:
- Code owners for modified files
- Security team for sensitive changes
- Team leads or architects

Reach out directly:
- Send a Teams/Slack message to the required reviewers
- Explain the urgency if applicable
- Offer to walk through the changes

If a required reviewer is unavailable:
Contact your project administrator to:
- Temporarily modify the branch policy
- Grant you bypass permissions (if appropriate)
- Reassign the required reviewer role

Using Azure CLI:

bash
# Check PR status including reviewer details
az repos pr show --id <PR_ID> --query "reviewers"

# List who's required vs optional
az repos pr policy list --id <PR_ID>
7Ensure branch is up to date

Some policies require your branch to be current with the target:

Check if this policy applies:
Look for "Check for linked work items" or "Require branches to be up to date" in policies.

Update your branch:

bash
# Fetch latest changes
git fetch origin

# Merge target branch into your feature branch
git checkout your-feature-branch
git merge origin/main

# Resolve any conflicts if they occur
# Then push the updated branch
git push origin your-feature-branch

Or rebase (cleaner history):

bash
git checkout your-feature-branch
git fetch origin
git rebase origin/main

# Force push after rebase
git push --force-with-lease origin your-feature-branch

Note: After updating, build validation will re-run automatically. Wait for it to pass before attempting completion again.

8Bypass policies (if you have permission)

If you have bypass permissions and the situation warrants it:

Complete with override:
1. On the PR page, click the dropdown arrow next to "Complete"
2. Select "Complete (override)" or look for bypass options
3. You may need to provide a reason for the override
4. Click Complete to merge despite policy violations

When bypassing is appropriate:
- Emergency hotfix for production issues
- Approved exception from project leadership
- Policy is incorrectly configured
- External dependency causing false failure

When NOT to bypass:
- To avoid doing a proper code review
- Because the build is "probably fine"
- Without understanding why the policy exists

Check if you have bypass permission:

bash
# Via Azure CLI - check your permissions
az devops security permission show --namespace-id <REPO_NAMESPACE> --subject <YOUR_ID>

Request bypass permission:
Contact your Azure DevOps administrator to grant:
- "Bypass policies when completing pull requests"
- "Exempt from policy enforcement"

These permissions are in: Project Settings > Repositories > Security

9Set up auto-complete for future PRs

Once all policies are on track to pass, enable auto-complete:

Enable auto-complete:
1. On your PR, click Set auto-complete
2. Configure merge options:
- Merge type (merge, squash, rebase)
- Delete source branch after merge
- Complete associated work items
3. Click Set auto-complete

The PR will automatically complete once all policies pass.

Auto-complete behavior:
- Waits for all required approvals
- Waits for build validation to succeed
- Waits for any external status checks
- Won't complete if new commits are pushed (must re-enable)

Using Azure CLI:

bash
# Enable auto-complete on a PR
az repos pr update --id <PR_ID> --auto-complete true

# Set merge strategy
az repos pr update --id <PR_ID> --merge-type squash

Note: Auto-complete won't bypass policies—it just waits for them to pass. If a policy cannot pass, you'll still need to address it manually.

Advanced notes

### Understanding Azure DevOps Branch Policy Architecture

Branch policies in Azure DevOps are evaluated at the repository level and can be set on:
- Specific branches (e.g., main, develop)
- Branch patterns (e.g., release/*, feature/*)
- Default branch (applies to main/master)

Policy inheritance works hierarchically:
1. Organization-level policies (if configured)
2. Project-level policies
3. Repository-level policies
4. Branch-specific policies

### Common TF401027 Variations

The TF401027 error code covers several permission and policy scenarios:

| Message Variant | Cause |
|-----------------|-------|
| "You need the Git 'PullRequestContribute' permission" | User lacks PR permissions |
| "You need to resolve policy violations" | Branch policies not satisfied |
| "You need the Git 'GenericContribute' permission" | Cannot contribute to repository |
| "identity 'Build\\GUID', scope 'repository'" | Pipeline service account lacks permissions |

### Configuring Branch Policies (for Admins)

bash
# View current policies on a branch
az repos policy list --repository-id <REPO_ID> --branch main

# Create a minimum reviewer policy
az repos policy approver-count create \
  --repository-id <REPO_ID> \
  --branch main \
  --minimum-approver-count 2 \
  --creator-vote-counts false \
  --allow-downvotes false \
  --reset-on-source-push true

### Pipeline Build Validation Best Practices

When configuring build validation policies:

yaml
# azure-pipelines.yml optimized for PR validation
trigger: none  # Don't run on direct pushes

pr:
  branches:
    include:
      - main
      - develop
  paths:
    exclude:
      - '*.md'
      - 'docs/*'

jobs:
- job: Validate
  displayName: 'PR Validation'
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - script: npm ci
    displayName: 'Install dependencies'
  - script: npm run lint
    displayName: 'Run linting'
  - script: npm test
    displayName: 'Run tests'
  - script: npm run build
    displayName: 'Build project'

### Handling Flaky Build Validations

If builds fail intermittently:

1. Re-queue the build: Sometimes infrastructure issues cause transient failures
2. Check for flaky tests: Use test retry mechanisms
3. Review build timeouts: Increase if needed
4. Parallel job limits: Organization may have hit concurrent job limits

bash
# Re-run a specific check on the PR
az repos pr policy queue --id <PR_ID> --evaluation-id <POLICY_EVAL_ID>

### Service Account Permissions for CI/CD

When pipelines need to interact with PRs:

bash
# Grant Build Service permissions to contribute to PRs
# In Azure DevOps: Project Settings > Repositories > Security
# Find: "<Project> Build Service (<Organization>)"
# Grant: Contribute to pull requests, Create branch

### External Status Checks

Third-party services can add status checks via the Azure DevOps Status API:

bash
# Check status of external policies
az repos pr policy evaluation list --id <PR_ID>

If an external check is stuck:
- Contact the service administrator
- Check webhook connectivity
- Look for failed Azure DevOps Service Hooks

### Audit Trail for Policy Bypasses

Bypasses are logged for compliance:
- View in Project Settings > Audit
- Filter by "Pull request policy override"
- Include bypass reason in completion notes

### Cross-Repository Policies

For monorepos or related repositories:
- Consider using path-based required reviewers
- Set up build validation per affected path
- Use CODEOWNERS-style automatic reviewer assignment

Frequently asked questions

What does "TF401027" mean?
The error "TF401027: You need to resolve policy violations before completing this pull request" appears in Azure DevOps (formerly VSTS/TFS) when you attempt to complete or merge a pull request that hasn't satisfied all the configured branch policies. Azure DevOps branch policies are rules that protect important branches like main or develop. When policies are set on a target branch, all pull requests targeting that branch must meet every policy requirement before completion is allowed.
How do I fix "TF401027"?
This Azure DevOps error occurs when you try to complete a pull request that hasn't met all the required branch policies. You'll need to satisfy the policy requirements such as reviewer approvals, successful builds, linked work items, or resolved comments before the PR can be merged.
What causes "TF401027"?
Required number of reviewer approvals not obtained Mandatory build validation pipeline failed or not run No work item linked to the pull request when required
Is the "TF401027" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading