> ## Documentation Index
> Fetch the complete documentation index at: https://docs.scanoss.com/llms.txt
> Use this file to discover all available pages before exploring further.

# When the Gate Blocks a Merge

> The three routes available when a policy blocks a pull request, how to request a policy approval, and how approvals are tracked and revoked.

## A Blocked Merge Is Not a Dead End

A blocked merge is not a dead end. It's a decision that needs to be made and recorded. When a policy blocks, the pull request gets the finding, the rule that fired, and the evidence. From there you have three honest routes.

## Route 1: Fix It

Upgrade or replace the component. The next scan re-evaluates and the gate clears on its own.

## Route 2: Correct the Finding

If the finding is wrong, because your own code matched its published copy or the wrong package was identified, triage it properly. Marking something original removes it from the gate because it genuinely doesn't apply.

## Route 3: Request an Approval

Sometimes the risk is real, understood, and accepted. From the finding, request a **Policy Approval**. It asks you for three things:

* A **category** for why it doesn't apply or is tolerable: the vulnerable code isn't reachable, mitigations are in place, it's under investigation, and so on.
* A **justification** in your own words.
* An **expiry**: 30 days, 90 days, a date you choose, or never.

The request sits **Pending** and doesn't, by itself, change the verdict. Someone with approval authority (an Admin) reviews it and either **Approves** or **Rejects** it, recording their own reason. Only an approval clears the finding, the gate keeps holding it until then.

<Note>
  **Give a request an expiry.** An approval with no expiry is a decision
  nobody will revisit. The Dashboard tracks how many are active and warns
  you when they're about to lapse. Use that.
</Note>

A rejected request, and a request still pending, both stay in the finding's history, nothing is discarded, so the record shows every attempt, not just the successful one.

## Finding What's Waiting on You

An Admin doesn't have to open policies one at a time to find pending requests. The project's **Policies** page has an **Approvals** tab, alongside **All Policies** and **Needs Attention**, counting what's still awaiting a decision across every policy attached to the project. It counts pending requests only, so it returns to zero once the queue is clear.

Approve or reject straight from the row. The **Status** filter switches to **Approved**, **Rejected**, or **Revoked**, which is also where an approval already granted can be revoked.

<Note>The queue covers one project at a time.</Note>

## Why This Matters

Whichever route you take, the reasoning is recorded. That's the difference between "we shipped it anyway" and "we assessed it, and here's who decided and why."

## What's Next

With a merge decision made and recorded, the next step is turning that record into evidence someone outside your team can consume, [exporting an SBOM](/en/latest/earnie/evidence/exporting-sboms).