> For the complete documentation index, see [llms.txt](https://help.aikido.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.aikido.dev/getting-started/core-functionalities/approval-inbox-for-ignored-issues.md).

# Approval Inbox for Ignored Issues

The approval inbox lets you require admin sign-off before users without ignore permissions can dismiss findings. Team members submit ignore requests with a reason, and admins review them in a central inbox before anything is removed from the feed.

## Use cases

* 🛡️ **Governance over risk acceptance**: Keep security leads in control of which findings get ignored.
* 👥 **Empower developers**: Let engineers triage false positives without handing out full ignore rights.
* 📋 **Audit trail**: Every request records who asked, why, and who approved or declined.

## Enabling ignore requests

Ignore requests are **not enabled by default**. Only workspace admins can turn them on from the [Triage settings](https://app.aikido.dev/settings/advanced).<br>

<figure><img src="/files/bbH6lr7lrABb0GZ0orxP" alt=""><figcaption></figcaption></figure>

## How it works

Whether a user can ignore an issue directly depends on their **Ignore permissions** (see [Setting Roles and Permissions](/getting-started/automated-user-management/setting-roles-and-permissions.md)) and whether **Allow Issue Ignore Requests** is enabled for your workspace:

* **With ignore permissions**: Users ignore findings immediately, the same as before.
* **Without ignore permissions, with ignore requests enabled**: Users submit an ignore request with a reason. The issue stays in the feed until an admin approves or rejects it.
* **Without ignore permissions, with ignore requests disabled**: Users cannot ignore findings or submit requests.

<img src="/files/uA2T7VNANDy8aEMrn4BV" alt="" width="375">

{% hint style="info" %}
Ignore requests apply to **individual subissues only**. Broader ignore rules (by path, CVE, or rule) still require ignore permissions.
{% endhint %}

When a user submits a request, admins are notified and can review it in the [Request Inbox](https://app.aikido.dev/inbox/issues/actions). The inbox lists the issue details, severity, location, requester, and their stated reason.

## Review ignore requests

{% stepper %}
{% step %}

### Open the inbox

Go to the [Request Inbox](https://app.aikido.dev/inbox/issues/actions), or click a pending notification in the **messages** indicator in the top navigation. The inbox shows a badge with the number of pending requests.<br>

<figure><img src="/files/mlIpGk3AqV8utoR3sPBV" alt="" width="375"><figcaption></figcaption></figure>
{% endstep %}

{% step %}

### Review a request

Click a row or the **Review** button on a pending request. The review modal shows the full issue context and the requester's reason.

<figure><img src="/files/3zJ3x8FSRBpK1C8fMi6X" alt=""><figcaption></figcaption></figure>
{% endstep %}

{% step %}

### Approve or reject

Click **Approve** to ignore the issue with the requester's stated reason, or **Reject** to decline the request and keep the issue open.<br>

<figure><img src="/files/0EnIg5MOi66JsVkxnyzG" alt=""><figcaption></figcaption></figure>
{% endstep %}
{% endstepper %}

### Pending and handled

The inbox has two tabs:

* **Pending**: Requests waiting for a decision.
* **Handled**: Requests you have already approved or rejected, including who reviewed them and when.

Use the search bar to filter by issue title or requester name. If you have a team filter active in Aikido, the inbox only shows requests for issues in that team.

### What happens after a decision

**Approved**: Aikido ignores the issue using the requester's reason. The finding moves to the [ignored view](https://app.aikido.dev/issues/ignored) and disappears from the main feed. The request is attributed to the original requester.

**Rejected**: The issue stays open or snoozed in the feed. The requester can submit a new request if needed.

## Notifications

Admins or users with ignore permissions see new ignore requests in the **messages** indicator in the top navigation. Each notification shows the request type and who submitted it. Click the notification to open the Request Inbox.<br>

<figure><img src="/files/SDPUxaJ5HD7BynHqJVco" alt=""><figcaption></figcaption></figure>

### Slack notifications

You can also receive Slack alerts when a new ignore request is submitted. Aikido posts a message to your chosen channel with a **Review in Aikido** button that links directly to the Request Inbox.

{% stepper %}
{% step %}

### Connect Slack

If you haven't already, connect Slack from [Slack integration settings](https://app.aikido.dev/settings/integrations/notifications/slack). See [Slack Notifications](/getting-started/chat-and-alerts/slack-notifications.md) for setup steps.
{% endstep %}

{% step %}

### Create a Slack alert

Go to the [Request Inbox](https://app.aikido.dev/inbox/issues/actions), open the **Ignore Issues** tab, and click **Manage Alerts** → **Slack**. Click **Create Alert** and select the channel that should receive ignore request notifications.
{% endstep %}

{% step %}

<figure><img src="/files/Q6pjksKKD3hn27m0yVEe" alt=""><figcaption></figcaption></figure>

### Test the alert

After saving, use **Send test alert** on the alert row to confirm messages arrive in the selected channel.
{% 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://help.aikido.dev/getting-started/core-functionalities/approval-inbox-for-ignored-issues.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.
