> For the complete documentation index, see [llms.txt](https://docs.flosum.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flosum.com/devops/settings/pull-requests-settings/adding-pull-request-approval-rules.md).
# Adding Pull Request Approval Rules
{% hint style="warning" %}
#### Written for the Old UI
This article was written for the old UI. The instructions are still usable, but the screenshots are outdated. In some cases, items referenced in the instructions have moved or changed. If you cannot find an item, see the [Where Did It Go](/devops/new-ui-ux-transition/where-did-it-go.md) article.
{% endhint %}
##  Overview
This article explains how a Pull Request Approval Rule works and how to add one. By default, a Pull Request does not require any reviews before it can be merged. With a Pull Request Approval Rule, administrators can enforce a minimum number of approvals before a Pull Request can be merged. Each rule defines which branches it applies to and how many approvals are required. The target branch of a Pull Request determines how many approvals it requires.
The rule can be configured with different scopes:
* **All Branches**: The rule applies to any branch not covered by a more specific rule.
* **Select**: The rule targets one or more explicitly selected branches.
* **Pattern**: The rule uses wildcard syntax to match branches by naming convention (e.g., `feature/*`, `release/v*`, `hotfix-*`).
{% hint style="info" %}
**Override Pull Request Approval Rule**
A Pull Request Approval Rule cannot be overridden. When the rule applies to the target branch, the Pull Request cannot be merged until the required number of reviewers approve it. This enforcement is by design. However, there are two approved ways to work around a Pull Request Approval Rule:
* Perform a **Smart Merge**, which does not require a review.
* Change the **Pull Request Approval Rule**.
{% endhint %}
### Pull Request Example
The following screenshot shows a Pull Request with an Approval Rule applied.
### Rule Hierarchy
When a rule's selected branches overlap with another rule, precedence determines which rule applies to the overlapping branch. The order of precedence, from highest to lowest, is:
* **Select** > **Pattern** > **All Branches**
The following screenshot shows two rules: one applies to **All Branches**, and the other applies only to the **main** branch. Because the **Select** rule takes precedence over the **All Branches** rule, any Pull Requests that target the **main** branch require 3 approvals instead of the 1 approval required for other branches.
{% hint style="info" %}
**Edge Cases**
The **Select** option does not let you assign the same branch to more than one rule. This prevents conflicts, such as one rule requiring three approvals for branch **X** while another requires only one.
The **Pattern** option does not let you save multiple rules with overlapping patterns. For example, you cannot save both `feature/*` and `feature/new*`, because the `feature/*` pattern already contains the `feature/new*` pattern.
{% endhint %}
## Adding Approval Rules
{% stepper %}
{% step %}
### Enable Approval Rules
1. Click **Settings** from the left sidebar menu.
2. Click the **General** tab.
3. Click **Pull Requests**.
4. If disabled, click the **Enable** toggle to enable approval rules.
{% endstep %}
{% step %}
### Select Branches
There are three methods for selecting which branches the Approval Rule will apply to.
**All Branches**
This selection applies the rule to every branch in your DevOps tenant.
1. Select the **All branches** option.
**Select**
This selection applies the rule to only the branches you select from the list.
1. Select the **Select** option.
2. Click the **Select branches** dropdown menu.
3. Select each of the branches to apply this rule to.
{% hint style="info" %}
Each selected branch shows a checkmark on the right. The dropdown also displays the number of selected and available branches. If you have many branches, use the search box to find them.
{% endhint %}
**Pattern**
This selection applies the rule to any branches that match the pattern you enter. You can add the wildcard character to the end of a pattern (\*) to match branches that start with your pattern and end with any other characters. For example, if you use the pattern `feature/*`, the table below shows how this rule affects your branches.
| Branches | Rule Applied |
|---|
| main |  |
| feature/addAccount |  |
| feature/removeAccount | |
| release/v1.2.3 | |
1. Select the **Pattern** option.
2. Enter the pattern to use for this rule in the textbox.
{% endstep %}
{% step %}
### Set Approval Count
The **Approval Count** is the number of reviewers who must approve a Pull Request before it can be merged. The count must be at least 1.
1. Enter the number of approvals required for this rule in the **Approval count** textbox.
{% endstep %}
{% step %}
### Add Rules
You can add multiple Approval Rules to the Pull Requests Settings. To learn which rule applies to a branch that is selected by multiple rules, see the **Rule Hierarchy** section above.
1. Click **Add rule**.
2. Configure the rule’s branch selection and approval count using the instructions above.
{% endstep %}
{% step %}
### Save Rules
Once you have completed defining your Pull Request Approval Rules, you must save them before they will apply to any new and active Pull Requests.
1. Click **Save**.
{% endstep %}
{% endstepper %}
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.flosum.com/devops/settings/pull-requests-settings/adding-pull-request-approval-rules.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
