> ## Documentation Index > Fetch the complete documentation index at: https://www.oplane.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Trigger filters for pull and merge request reviews > Use trigger filters in Oplane workspace settings to choose which pull requests and merge requests Oplane reviews automatically, by target branch, source branch, or changed path. Trigger filters decide which pull requests (GitHub) and merge requests (GitLab) Oplane reviews automatically. You can filter on the target branch, the source branch, or the paths of changed files. This page explains how filters and their patterns work, with examples. For what triggers a review in the first place, see [How reviews work](/docs/how-it-works/reviews). > [!NOTE] > > You need to be the workspace **Owner** or an **Org Admin** to change trigger filters. See [Workspace permissions](/docs/administration/roles#workspace-permissions). ## How trigger filters work Without trigger filters, Oplane reviews every PR or MR in the repository. When you add a filter, Oplane only reviews a PR or MR automatically when a filter matches it. You can filter on: * **Target branch**: the branch the PR or MR merges into. * **Source branch**: the branch the changes come from. * **Path**: the paths of the files the PR or MR changes. The filter matches when any changed file matches, so a PR that changes one matching file and many other files is still reviewed. How filters behave: * **Each repository has its own filters.** You set them per linked repository in a workspace. * **Filters are combined with a logical `OR`.** Oplane reviews a PR or MR when any one filter matches. It doesn't need all of them to match. * **Filters only affect automatic reviews.** If you comment `oplane review`, `@oplane review`, `oplane run`, or `@oplane run` on a PR or MR, Oplane reviews it regardless of your filters. Because filters are combined with `OR`, you can't use two filters to narrow each other down. For example, a **Target branch** filter `/main` and a **Path** filter `services/payments/**` review every PR into `main` and every PR that touches `services/payments/`. To review fewer PRs, make a single filter more specific. ## Add a trigger filter 1. Open the workspace connected to the repository. 2. Go to workspace settings and find the linked repository. Make sure **Enable PR analysis** (or **Enable MR analysis** for GitLab) is on. **Trigger filters** only appear while analysis is on. 3. Under **Trigger filters**, click **Filter**. 4. Under **Filter on**, pick **Target branch**, **Source branch**, or **Path**. 5. Under **Pattern**, enter one pattern per line. 6. Click **Add filter**. To change a filter, click its edit icon. To remove it, click its delete icon. When no filters are active, the section says that every PR or MR is reviewed. ## Writing patterns Each line of a filter is a pattern that says what Oplane **reviews**. A line that starts with `!` is an exclusion: it takes back something a line above it included. > [!WARNING] > > **Start with what to include.** A filter that only contains exclusions (lines that start with `!`) matches nothing, so Oplane stops reviewing PRs or MRs automatically. To review everything except some paths or branches, put `**` on the first line, then add your exclusions below it. Oplane reads the lines from top to bottom, and the **last line that matches decides**. Order matters: | Pattern | `release/legacy` | `release/2026.10` | | - | - | - | | `release/**` `!release/legacy` | Not reviewed | Reviewed | | `!release/legacy` `release/**` | Reviewed | Reviewed | In the second pattern, `release/**` comes last and includes `release/legacy` again. ### Pattern syntax | Pattern | Matches | Doesn't match | | - | - | - | | `**` | Everything | | | `release/*` | `release/2026.10` | `release/2026/10` | | `release/**` | `release/2026.10`, `release/2026/10` | `hotfix/1` | | `main` | `main`, `feature/main` | `maintenance` | | `/main` | `main` | `feature/main` | | `*.md` | `README.md`, `docs/guide/setup.md` | `README.txt` | | `docs/` | `docs/setup.md`, `api/docs/setup.md` | `docs.md` | | `/docs/` | `docs/setup.md` | `api/docs/setup.md` | | `release-?` | `release-1` | `release-10` | | `v[12]/**` | `v1/api.ts`, `v2/api.ts` | `v3/api.ts` | Some rules that often catch people out: * **A pattern without a `/`, or with only a `/` at the end, matches at any level.** This applies to branch names too, so `main` also matches a branch called `feature/main`, and `docs/` matches `api/docs/`. Start the pattern with `/` to match from the top only, for example `/main`. * **`*` doesn't cross a `/`.** `release/*` matches `release/2026.10` but not `release/2026/10`. Use `**` to match across several levels. * **Patterns are case-sensitive.** `Main` doesn't match `main`. * **Lines that start with `#` are comments.** Oplane ignores them and blank lines. * **To review everything, delete the filter.** Reviewing every PR or MR is the default. ## Examples > **Only review PRs into main and release branches** > > **Filter on:** Target branch > > ```text theme={null} > /main > release/** > ``` > > The `/` at the start of `/main` stops it from matching branches such as `feature/main`. > **Skip dependency update branches** > > **Filter on:** Source branch > > ```text theme={null} > ** > !dependabot/** > !renovate/** > ``` > > `**` includes every branch, then the two exclusions remove the branches that dependency bots create. Without the first line, nothing would be reviewed. > **Skip documentation-only changes** > > **Filter on:** Path > > ```text theme={null} > ** > !docs/** > !**/*.md > ``` > > A PR that only changes files under `docs/` or Markdown files isn't reviewed. A PR that also changes code is reviewed, because a path filter matches when any changed file matches. > **Review one service in a monorepo** > > **Filter on:** Path > > ```text theme={null} > services/payments/** > libs/auth/** > ``` > > Oplane reviews PRs that change the payments service or the shared authentication library. PRs that only change other services aren't reviewed. > **Review a folder except its tests** > > **Filter on:** Path > > ```text theme={null} > src/** > !**/test/** > ``` > > Changes under `src/` are reviewed, except files in any `test` folder. A PR that only changes tests isn't reviewed. ## Renamed files and very large changes When a file is renamed or moved, a path filter checks both the old and the new path. If a PR or MR changes so many files that Oplane can't get the full list from GitHub or GitLab, Oplane reviews it rather than risk skipping a change that matches. ## Limits | Limit | Value | | - | - | | Patterns per filter | 20, not counting comments and blank lines | | Characters per pattern | 500 | | `*` wildcards in one part of a path | 2 (the parts between `/`). Split the pattern with `/` if you need more. | | Allowed characters | Letters, digits, spaces, and `/ . _ - + ~ @ * ? ! [ ] { } \` | If a filter breaks a limit, Oplane shows an error that explains what to fix and doesn't save the filter. ## Read next * [How reviews work](/docs/how-it-works/reviews), for what triggers a review and what it produces. * [Review pull and merge requests](/docs/find/pull-and-merge-requests), to set up reviews and act on the comment. * [Limits](/docs/reference/limits), for the other limits on reviews. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.