Org, project, and repo settings hierarchy

How ADO Pilot resolves configuration across organization, project, and repository scopes — override semantics for scalars, additive merging for arrays.

Last updated 2026-05-05

ADO Pilot evaluates settings at three scopes — organization, project, and repository. You set defaults at the organization level, narrow them at the project level, and lock down individual repositories where needed. The resolved configuration for any pull request is the merge of all three.

The three scopes

Organization — Widest scope. Acts as the default for every project and repository.
Project — Inherits from the organization. Overlays its own values on top.
Repository — Narrowest scope. Wins over project and organization for any field it sets.

Each scope can leave a field unset, in which case the next-broader scope provides the value.

Merge rules

ADO Pilot merges settings differently depending on the field type.

Scalar fields use override semantics — the most-specific scope wins.

Field	Type	Default	Scopes that take effect
`enabled`	boolean	`true`	Org / project / repo
`reviewOnPush`	boolean	`true`	Org / project / repo

If the organization sets enabled: true and a repository sets enabled: false, that repository is disabled. The repository value wins outright.

Org-only scalar fields are honoured only at the organization scope. Setting them at the project or repository level has no effect.

Field	Type	Default	Scope
`allowManualInvocation`	boolean	`true`	Org only

Exception — `enabled: false` short-circuits

When enabled is false at any scope, evaluation stops there. ADO Pilot does not consult narrower scopes — a project with enabled: false skips review even if a repository underneath it sets enabled: true. This makes enabled: false a clean way to pause reviews at any level without rewriting downstream configuration.

Array fields use additive semantics — patterns from every scope combine.

Field	Type	Default
`targetBranchFilters`	string array	`["*"]`
`fileExclusionPatterns`	string array	`[]`

If the organization excludes *.lock and a repository excludes *.generated.cs, both patterns are active for that repository.

How effective settings are computed

For every PR webhook, ADO Pilot resolves settings in this order:

Load organization-level settings.
Overlay project-level settings.
Overlay repository-level settings.
The result is the effective settings used for that review.

Example: a multi-project organization

Organization defaults
  enabled: true
  targetBranchFilters: ["main", "release/*"]
  fileExclusionPatterns: ["*.lock", "**/node_modules/**"]

  Project A  (no overrides)
    Backend repo
      effective enabled: true
      effective targetBranchFilters: ["main", "release/*"]
      effective fileExclusionPatterns: ["*.lock", "**/node_modules/**"]

  Project B
    targetBranchFilters: ["main", "release/v*", "hotfix/*"]
    Frontend repo
      enabled: false
      effective enabled: false   (repo wins)
      effective targetBranchFilters: ["main", "release/v*", "hotfix/*"]
      effective fileExclusionPatterns: ["*.lock", "**/node_modules/**"]

Choosing a starting point

Set company-wide rules at the organization level — branch filters that match your release model, exclusions for build artifacts that every team produces.
Use the project level for team-specific workflows — for example, a backend project that needs to exclude generated protobuf files.
Use the repository level for one-off cases — disabling reviews on an experimental repo, or adding exclusions for a vendored library.