Stop Manually Tagging Reviewers: How Azure DevOps Automatically Assigns PR Reviewers

One of the most common problems in code review workflows is simple but frustrating:

“Who should review this pull request?”

Developers open a PR and then try to guess:

• Which team owns this code

• Which specialist needs to approve the change

• Who is available to review

When the wrong reviewer is tagged, the PR sits idle until someone redirects it to the right person.

Azure DevOps solves this problem with Automatically Included Reviewers, commonly referred to as required reviewers.

This feature allows teams to automatically assign reviewers to pull requests based on the files being changed.

For example:

• changes to /src/auth/** automatically add the Security team

• changes to *.sql automatically add the DBA team

• changes to /infrastructure/** automatically add DevOps engineers

Developers no longer need to remember who owns which code path. Azure DevOps assigns reviewers automatically the moment the PR is created.

In this guide, we’ll cover:

• how required reviewers work in Azure DevOps

• path-based reviewer assignment using filters

• when to use required vs optional reviewers

• group-based reviewer strategies for scaling teams

• real-world configurations used by enterprise teams

By the end, you’ll understand exactly how to implement CODEOWNERS-style review workflows in Azure DevOps.

How Automatic Reviewers Work in Azure DevOps

Automatic reviewers, officially called “Automatically included reviewers” in the Azure DevOps UI, are a branch policy that adds specific people or groups to a pull request whenever the PR modifies files matching a configured path filter. The reviewer is added the moment the PR is created; the author doesn’t need to remember who to tag.

There are two types of automatic reviewers:

Required reviewers block the PR from being completed until they vote “Approve.” If a required reviewer hasn’t voted, the Complete button stays grayed out, regardless of how many other reviewers have approved.

Optional reviewers are added to the PR and notified, but their approval is not required for merge. They can still comment and vote, but their absence doesn’t block completion.

The system works by matching file paths changed in the PR against path filter patterns configured in the branch policy. When a match is found, the associated reviewer (user or group) is automatically added to the PR. If no path filter is configured, the reviewer is added to every PR targeting that branch.

Path Filter Syntax and Matching Rules

Path filters determine which file changes trigger the auto-reviewer. Understanding the syntax is critical, a misconfigured filter either triggers on everything or misses the files you intended.

Syntax Reference

Critical Detail: vs *

This is the most common misconfiguration. A single * matches files in the immediate directory only — it does not recurse into subdirectories. A double ** matches recursively through all subdirectories.

If your project has nested directories (most do), use ** in almost all cases:

Multiple Path Filters

You can add multiple path filters to a single auto-reviewer policy by separating them with semicolons:

/src/auth/**;/src/security/**

/src/auth/**;/src/security/**

This adds the reviewer when any of the matched paths are changed in the PR.

Exclusion Filters

Prefix a path with ! to exclude it. Exclusions are evaluated after inclusions:

/src/**;!/src/tests/**

/src/**;!/src/tests/**

This triggers the reviewer for any file under /src/ except test files. Useful when you want a reviewer on production code but not on test changes.

Required vs Optional Reviewers: When to Use Each

Decision Framework

Group vs Individual Reviewer Strategy

Why Groups Are Almost Always Better

When you configure an auto-reviewer policy, you can assign either an individual user or an Azure DevOps security group. For any team larger than 2 people, groups are the correct choice.

How Group Approval Works

When a group is set as a required reviewer, the requirement is satisfied when any one member of the group votes “Approve.” Not all members need to approve, just one.

This is important: if you add the “Backend Team” group (10 members) as a required reviewer, the PR is unblocked the moment any single backend team member approves. The other 9 don’t need to vote.

If you need multiple approvals from the same team (e.g., 2 backend engineers must approve), use the “Minimum number of reviewers” branch policy in combination with auto-reviewers. Set minimum reviewers to 2, and auto-include the Backend Team group. Now the PR needs 2 total approvals and at least one must come from the auto-included group.

Recommended Group Structure

Create dedicated security groups in Azure DevOps for reviewer purposes:

Name groups with a PR-Reviewers- prefix so they’re easy to identify and distinguish from general access groups.

Handling Reviewer Absence and Vacations

Required reviewers that block PRs create a real operational risk when people go on vacation, get sick, or leave the company. Here’s how to handle each scenario.

Prevention: Use Groups (Not Individuals)

The single best thing you can do is never assign an individual as a required reviewer. If the “Security Team” group has 3 members and one is on vacation, the other 2 can still approve. If “Jane Doe” is the required reviewer and she’s on vacation, every PR touching her paths is blocked.

Planned Absence (Vacation, Conference, Parental Leave)

Before the absence:

1. Verify the reviewer is part of a group, not assigned individually

2. Verify the group has at least 2 other active members

3. If the group is too small (only 2 members and 1 is leaving), temporarily add another qualified team member to the group

4. Communicate to the team: “I’m out from X to Y — [other group members] can approve PRs on my paths”

No policy changes needed if groups are set up correctly. The group continues to function with the remaining members.

Unplanned Absence (Sick Day, Emergency)

Same as planned absence if groups are used. If an individual is assigned, a Project Administrator needs to either:

1. Temporarily add another reviewer to the policy (UI: Project Settings → Repos → Policies → branch → Automatically included reviewers → Edit the entry → add another reviewer)

2. Or temporarily change the policy from “Required” to “Optional” until the reviewer returns

Reviewer Leaves the Company

1. Remove them from all reviewer groups (they should be deactivated in Azure AD/Entra ID automatically)

2. Audit all auto-reviewer policies to check if they were assigned individually anywhere (search across repos)

3. Add a replacement to the group

4. If they were the last member of a reviewer group, assign a new member immediately — an empty required reviewer group blocks all PRs with no one able to approve

Audit script to find individual reviewer assignments:

#!/bin/bash
# find-individual-reviewers.sh
# Lists all auto-reviewer policies that use individual users (not groups)

ORG="<https://dev.azure.com/your-org>"
PROJECT="your-project"

REPO_IDS=$(az repos list --org "$ORG" --project "$PROJECT" --query "[].id" --output tsv)

for REPO_ID in $REPO_IDS; do
  REPO_NAME=$(az repos show --id "$REPO_ID" --org "$ORG" --project "$PROJECT" --query "name" --output tsv)

  POLICIES=$(az repos policy list \\
    --repository-id "$REPO_ID" \\
    --org "$ORG" \\
    --project "$PROJECT" \\
    --query "[?type.displayName=='Required reviewers']" \\
    --output json 2>/dev/null)

  if [ "$POLICIES" != "[]" ] && [ -n "$POLICIES" ]; then
    echo "📋$REPO_NAME:"
    echo "$POLICIES" | jq -r '.[] | "  Branch: \\(.settings.scope[0].refName // "all") | Reviewer: \\(.settings.requiredReviewerIds | join(", ")) | Path: \\(.settings.filenamePatterns | join("; ") // "all files")"'
  fi
done

#!/bin/bash
# find-individual-reviewers.sh
# Lists all auto-reviewer policies that use individual users (not groups)

ORG="<https://dev.azure.com/your-org>"
PROJECT="your-project"

REPO_IDS=$(az repos list --org "$ORG" --project "$PROJECT" --query "[].id" --output tsv)

for REPO_ID in $REPO_IDS; do
  REPO_NAME=$(az repos show --id "$REPO_ID" --org "$ORG" --project "$PROJECT" --query "name" --output tsv)

  POLICIES=$(az repos policy list \\
    --repository-id "$REPO_ID" \\
    --org "$ORG" \\
    --project "$PROJECT" \\
    --query "[?type.displayName=='Required reviewers']" \\
    --output json 2>/dev/null)

  if [ "$POLICIES" != "[]" ] && [ -n "$POLICIES" ]; then
    echo "📋$REPO_NAME:"
    echo "$POLICIES" | jq -r '.[] | "  Branch: \\(.settings.scope[0].refName // "all") | Reviewer: \\(.settings.requiredReviewerIds | join(", ")) | Path: \\(.settings.filenamePatterns | join("; ") // "all files")"'
  fi
done

Check the output for reviewer IDs that are individual users rather than group IDs. Individual user IDs in Azure DevOps are UUIDs — group IDs are also UUIDs but you can cross-reference with az devops security group list to identify which are groups.

Emergency: Required Reviewer Is Blocking a Critical PR

If a required reviewer is unavailable and the PR is urgent:

Option 1 (preferred): Have a Project Administrator temporarily change the auto-reviewer policy from “Required” to “Optional,” complete the PR, then change it back.

Option 2: A user with “Bypass policies when completing pull requests” permission can merge the PR. This bypasses all policies, not just the reviewer requirement, and is logged in the PR audit trail.

Option 3: Add the blocking reviewer to a group with another available member, so the other member can satisfy the requirement. This is a workaround — the group approach should be the default from the start.

Step-by-Step: Configure Path-Based Reviewers

Via the Web UI

Step 1: Go to Project Settings → Repos → Repositories → [Select repo] → Policies → [Select branch] (e.g., main)

Step 2: Scroll to Automatically included reviewers and click + Add new auto reviewer policy

Step 3: Configure the policy:

• Reviewer: Search and select a user or group (use groups)

• Path filter: Enter the file path pattern. Examples:

  • /src/api/** — all files under the API directory

  • .sql;/migrations/** — all SQL files and all migration files

  • /src/auth/**;/src/security/** — auth and security directories

  • /infrastructure/**;/.pipelines/** — infra and CI/CD files

• Required: Toggle ON for paths that must have specialist sign-off; OFF for advisory reviews

• Allow requestors to approve their own changes: Leave OFF (the PR author shouldn’t approve their own changes even if they’re in the reviewer group)

Step 4: Click Save

Step 5: Test by creating a PR that modifies a file matching the path filter. The reviewer should appear automatically in the Reviewers section.

Via the Azure CLI

# Add required reviewer for security paths
az repos policy required-reviewer create \\
  --blocking true \\
  --branch main \\
  --enabled true \\
  --repository-id <REPO_ID> \\
  --required-reviewer-ids "<GROUP_OR_USER_ID>" \\
  --path-filter "/src/auth/**;/src/security/**;/src/crypto/**" \\
  --message "Security team review required for auth/security changes"

# Add optional reviewer for documentation
az repos policy required-reviewer create \\
  --blocking false \\
  --branch main \\
  --enabled true \\
  --repository-id <REPO_ID> \\
  --required-reviewer-ids "<GROUP_OR_USER_ID>" \\
  --path-filter "/docs/**" \\
  --message "Tech writers - optional review for documentation changes"

# Add required reviewer for security paths
az repos policy required-reviewer create \\
  --blocking true \\
  --branch main \\
  --enabled true \\
  --repository-id <REPO_ID> \\
  --required-reviewer-ids "<GROUP_OR_USER_ID>" \\
  --path-filter "/src/auth/**;/src/security/**;/src/crypto/**" \\
  --message "Security team review required for auth/security changes"

# Add optional reviewer for documentation
az repos policy required-reviewer create \\
  --blocking false \\
  --branch main \\
  --enabled true \\
  --repository-id <REPO_ID> \\
  --required-reviewer-ids "<GROUP_OR_USER_ID>" \\
  --path-filter "/docs/**" \\
  --message "Tech writers - optional review for documentation changes"

The --blocking true flag makes the reviewer required. --blocking false makes them optional.

Via the REST API (for Automation)

For programmatic management (CI/CD pipelines, custom tooling), use the REST API directly:

curl -X POST \\
  "<https://dev.azure.com/{org}/{project}/_apis/policy/configurations?api-version=7.1>" \\
  -H "Content-Type: application/json" \\
  -H "Authorization: Basic$(echo -n ":$PAT" | base64)" \\
  -d '{
    "isEnabled": true,
    "isBlocking": true,
    "type": { "id": "fd2167ab-b0d6-447e-a3e2-a9f3a6519de2" },
    "settings": {
      "requiredReviewerIds": ["<GROUP_ID>"],
      "filenamePatterns": ["/src/auth/**", "/src/security/**"],
      "addedFilesOnly": false,
      "message": "Security team review required",
      "scope": [{
        "repositoryId": "<REPO_ID>",
        "refName": "refs/heads/main",
        "matchKind": "exact"
      }]
    }
  }'

curl -X POST \\
  "<https://dev.azure.com/{org}/{project}/_apis/policy/configurations?api-version=7.1>" \\
  -H "Content-Type: application/json" \\
  -H "Authorization: Basic$(echo -n ":$PAT" | base64)" \\
  -d '{
    "isEnabled": true,
    "isBlocking": true,
    "type": { "id": "fd2167ab-b0d6-447e-a3e2-a9f3a6519de2" },
    "settings": {
      "requiredReviewerIds": ["<GROUP_ID>"],
      "filenamePatterns": ["/src/auth/**", "/src/security/**"],
      "addedFilesOnly": false,
      "message": "Security team review required",
      "scope": [{
        "repositoryId": "<REPO_ID>",
        "refName": "refs/heads/main",
        "matchKind": "exact"
      }]
    }
  }'

The policy type ID fd2167ab-b0d6-447e-a3e2-a9f3a6519de2 is the fixed identifier for “Required reviewers” policies in Azure DevOps.

Example Configurations: Monorepo, Microservices, and Platform Teams

Monorepo Configuration

A monorepo contains multiple services, shared libraries, and infrastructure in a single repository. The challenge is ensuring the right team reviews the right code without everyone reviewing everything.

Repository structure:

Auto-reviewer configuration:

Key monorepo considerations:

Cross-service PRs trigger multiple reviewer groups. A PR that changes /services/payment-service/ and /shared/database-lib/ will auto-include both the Payment Team and the Platform Team as required reviewers. Both must approve. This is correct behavior — cross-cutting changes should get broader review.

If cross-service PRs are frequent and the multi-reviewer requirement slows the team down, reconsider whether those paths should share a reviewer group or whether the shared library should have its own repo.

Microservices Configuration (Multi-Repo)

In a microservices architecture with separate repositories per service, each repo has its own policies. The challenge is applying consistent policies across all repos.

Per-service repo configuration (e.g., user-service repo):

Cross-repo consistency script:

#!/bin/bash
# apply-reviewer-policies.sh
# Applies standard reviewer policies to all service repos

ORG="<https://dev.azure.com/your-org>"
PROJECT="your-project"
BRANCH="main"
DBA_GROUP_ID="<DBA_GROUP_ID>"
DEVOPS_GROUP_ID="<DEVOPS_GROUP_ID>"
SECURITY_GROUP_ID="<SECURITY_GROUP_ID>"

REPO_IDS=$(az repos list --org "$ORG" --project "$PROJECT" --query "[].id" --output tsv)

for REPO_ID in $REPO_IDS; do
  REPO_NAME=$(az repos show --id "$REPO_ID" --org "$ORG" --project "$PROJECT" --query "name" --output tsv)
  echo "Configuring reviewers for:$REPO_NAME"

  # DBA review for SQL and migrations
  az repos policy required-reviewer create \\
    --blocking true \\
    --branch "$BRANCH" \\
    --enabled true \\
    --repository-id "$REPO_ID" \\
    --required-reviewer-ids "$DBA_GROUP_ID" \\
    --path-filter "*.sql;/migrations/**" \\
    --message "DBA review required for schema changes" \\
    --org "$ORG" --project "$PROJECT" \\
    2>/dev/null && echo "  ✓ DBA reviewer policy" || echo "  ⚠ DBA policy exists or failed"

  # DevOps review for deployment and pipeline changes
  az repos policy required-reviewer create \\
    --blocking true \\
    --branch "$BRANCH" \\
    --enabled true \\
    --repository-id "$REPO_ID" \\
    --required-reviewer-ids "$DEVOPS_GROUP_ID" \\
    --path-filter "/deploy/**;/.pipelines/**;/infrastructure/**" \\
    --message "DevOps review required for deployment changes" \\
    --org "$ORG" --project "$PROJECT" \\
    2>/dev/null && echo "  ✓ DevOps reviewer policy" || echo "  ⚠ DevOps policy exists or failed"

  # Security review for auth code
  az repos policy required-reviewer create \\
    --blocking true \\
    --branch "$BRANCH" \\
    --enabled true \\
    --repository-id "$REPO_ID" \\
    --required-reviewer-ids "$SECURITY_GROUP_ID" \\
    --path-filter "/src/auth/**;/src/security/**" \\
    --message "Security review required for auth changes" \\
    --org "$ORG" --project "$PROJECT" \\
    2>/dev/null && echo "  ✓ Security reviewer policy" || echo "  ⚠ Security policy exists or failed"

  echo "---"
done

#!/bin/bash
# apply-reviewer-policies.sh
# Applies standard reviewer policies to all service repos

ORG="<https://dev.azure.com/your-org>"
PROJECT="your-project"
BRANCH="main"
DBA_GROUP_ID="<DBA_GROUP_ID>"
DEVOPS_GROUP_ID="<DEVOPS_GROUP_ID>"
SECURITY_GROUP_ID="<SECURITY_GROUP_ID>"

REPO_IDS=$(az repos list --org "$ORG" --project "$PROJECT" --query "[].id" --output tsv)

for REPO_ID in $REPO_IDS; do
  REPO_NAME=$(az repos show --id "$REPO_ID" --org "$ORG" --project "$PROJECT" --query "name" --output tsv)
  echo "Configuring reviewers for:$REPO_NAME"

  # DBA review for SQL and migrations
  az repos policy required-reviewer create \\
    --blocking true \\
    --branch "$BRANCH" \\
    --enabled true \\
    --repository-id "$REPO_ID" \\
    --required-reviewer-ids "$DBA_GROUP_ID" \\
    --path-filter "*.sql;/migrations/**" \\
    --message "DBA review required for schema changes" \\
    --org "$ORG" --project "$PROJECT" \\
    2>/dev/null && echo "  ✓ DBA reviewer policy" || echo "  ⚠ DBA policy exists or failed"

  # DevOps review for deployment and pipeline changes
  az repos policy required-reviewer create \\
    --blocking true \\
    --branch "$BRANCH" \\
    --enabled true \\
    --repository-id "$REPO_ID" \\
    --required-reviewer-ids "$DEVOPS_GROUP_ID" \\
    --path-filter "/deploy/**;/.pipelines/**;/infrastructure/**" \\
    --message "DevOps review required for deployment changes" \\
    --org "$ORG" --project "$PROJECT" \\
    2>/dev/null && echo "  ✓ DevOps reviewer policy" || echo "  ⚠ DevOps policy exists or failed"

  # Security review for auth code
  az repos policy required-reviewer create \\
    --blocking true \\
    --branch "$BRANCH" \\
    --enabled true \\
    --repository-id "$REPO_ID" \\
    --required-reviewer-ids "$SECURITY_GROUP_ID" \\
    --path-filter "/src/auth/**;/src/security/**" \\
    --message "Security review required for auth changes" \\
    --org "$ORG" --project "$PROJECT" \\
    2>/dev/null && echo "  ✓ Security reviewer policy" || echo "  ⚠ Security policy exists or failed"

  echo "---"
done

Platform Team Configuration

Platform teams maintain shared infrastructure, SDKs, and developer tools used by all product teams. Their review requirements are the inverse of product teams: they need product team reviewers when platform changes might break consumers.

Platform SDK repo configuration:

Troubleshooting Required Reviewer Issues

“Required reviewer was auto-added but I don’t know why”

A path filter in the “Automatically included reviewers” policy matched one or more files in the PR.

How to find the triggering policy:

1. Go to Project Settings → Repos → Repositories → [repo] → Policies → [branch]

2. Scroll to Automatically included reviewers

3. Check each entry’s path filter against the files changed in the PR

4. The entry with a matching path filter is the one that triggered

If the PR modifies files across multiple path filters, multiple reviewers will be added. Each matching policy adds its reviewer independently.

“Auto-reviewer is required but they left the company”

Their Azure AD/Entra ID account was deactivated, but the policy still references their user ID. The PR is effectively blocked because no one can approve on behalf of a deactivated user.

Fix: A Project Administrator must edit the auto-reviewer policy to remove the deactivated user and replace them with an active user or group. This is the strongest argument for using groups instead of individuals — groups survive personnel changes.

“I’m in the reviewer group but wasn’t added to the PR”

Possible causes:

1. The PR doesn’t modify any files matching the path filter. Check the changed files list against the path filter pattern.

2. The path filter uses (single level) instead of * (recursive). If your file is in a subdirectory, won’t match it.

3. The policy is on a different branch. Auto-reviewer policies are per-branch — a policy on main doesn’t apply to PRs targeting develop.

4. The policy is disabled. Check if the toggle is set to “Enabled.”

“Two auto-reviewer policies conflict: PR needs both teams but one always blocks”

This is expected behavior, not a conflict. When multiple auto-reviewer policies match the same PR, all matching reviewers are added. If both are required, both must approve. This is the correct outcome for cross-cutting changes.

If this creates too much friction, consider whether the overlapping paths should be consolidated under a single reviewer group, or whether one of the policies should be changed from “Required” to “Optional.”

“PR author is auto-included as a reviewer and can self-approve”

The “Allow requestors to approve their own changes” setting is checked on the auto-reviewer policy. When the PR author is a member of the auto-included group, they can satisfy the requirement by approving their own PR.

Fix: Edit the auto-reviewer policy and uncheck “Allow requestors to approve their own changes.” The PR author’s approval will no longer count toward this required reviewer, even though they’re in the group.

“Auto-reviewer is added but the PR doesn’t show them as ‘Required’”

The policy has --blocking false (optional, not required). The reviewer is added for notification and visibility but their approval doesn’t block completion.

Fix: If they should be required, edit the policy and set it to blocking (--blocking true in CLI, or toggle “Required” in the UI).

How AI Code Review Complements Required Reviewers

Required reviewers ensure the right people see the right code. But human reviewers, even specialists, are inconsistent at catching mechanical issues: security vulnerabilities they’ve seen a hundred times, performance patterns that are easy to overlook, and quality issues that are tedious to catch on every PR.

CodeAnt AI, used by Fortune 500 development teams on Azure DevOps, adds an automated review layer that runs alongside human reviewers. When a PR is created, CodeAnt AI reviews every line and posts inline findings for security vulnerabilities, code quality issues, and performance problems, with one-click fixes developers can apply directly from the PR. This means the human required reviewer can focus on architecture, business logic, and design decisions while the AI handles the mechanical checks.

The combination works like this: auto-included reviewers ensure the right humans review the right code paths, while CodeAnt AI ensures every line of every PR gets consistent quality and security analysis regardless of which human is reviewing. Quality gates block builds when critical issues are found, and leadership dashboards give engineering leaders visibility into code health across the organization.

For setup instructions, see the cloud setup guide or self-hosted setup guide.