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

# Manage Rule Alerts

> Review, dismiss, and act on alerts raised by data rules across events, batches, and reports.

When a data rule's expression matches a record, Mangrove raises an **alert**. This page covers where alerts surface, how to triage them, and how to act on them without losing audit history.

## Where alerts surface

Alerts from data rules appear in three places:

| Location         | What you see                                                                                                                                                             |
| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Event drawer** | Events flagged by an Event Data rule show an alert card in the event detail drawer with the rule name, the failing condition, and the rule expression.                   |
| **Batch detail** | Batches flagged by a Batch Calculations rule list their rule alerts in the batch detail page. The card surfaces the effective period range so you can scope the issue.   |
| **Reports**      | Alerts on records included in a report propagate to that report. The report flags how many alerted records it contains so reviewers can address them before signing off. |

You can also see all triggered records for a single rule by opening **Project Settings → Data Rules** and clicking into the rule.

## Triage an alert

<Steps>
  <Step title="Open the alert">
    From an event drawer, batch page, or rule details page, click the alert card. The card shows:

    * The **rule name** and a link back to the rule definition
    * The **rule expression** that triggered the alert (with the matching variable highlighted)
    * The **value** that caused the match
    * The **time** the alert was triggered
  </Step>

  <Step title="Decide what to do">
    Three choices:

    * **Fix the data.** If the alert is real, correct the underlying datapoint or model input. Re-running the calculation re-evaluates the rule; if the data is now in range, the alert is automatically resolved.
    * **Dismiss the alert.** If the alert is a known false positive or doesn't apply to this record, dismiss it with a reason. The alert is hidden from the active list but preserved for audit.
    * **Adjust the rule.** If the alert reveals that the rule itself is wrong (too aggressive, wrong threshold), edit the rule expression. Editing re-evaluates the rule against the project's data and replaces its existing alerts with the new results — the previous alerts are not kept.
  </Step>

  <Step title="Dismiss with a reason">
    Click **Dismiss alert** and provide a reason. The reason is stored alongside the alert and visible to anyone reviewing the rule's history or the affected report. Dismissed alerts appear with a `dismissed` tag rather than `fail`.

    <Note>
      Dismissing an alert does not change the underlying datapoint or batch — it only changes how the alert is surfaced. If the data is recalculated and the rule still matches, a fresh alert can be raised.
    </Note>
  </Step>
</Steps>

## Reviewing rule activity

Open a rule from **Project Settings → Data Rules** to see its full evaluation history:

* **Alerted Records** — every record the rule currently matches, with status (`fail`, `pass`, `dismissed`), date range, tracking ID, and source.
* **Test rule** — re-run the expression against recent project data without saving anything new. Useful when you want to gauge whether a rule is still firing as expected.

For Event Data rules, click a record to open the event drawer. For Batch Calculations rules, click a batch to open the batch preview drawer with the calculation context.

## Stopping a noisy rule

If a rule is producing alerts you don't want to act on:

* **Shorten the effective period.** Set or pull in the **Effective to** date so the rule stops applying to new records. History inside the original range is preserved.
* **Edit the expression.** Tighten or loosen the rule. Editing re-evaluates the rule and replaces its existing alerts with the new results — the previous alerts are not kept.
* **Delete the rule.** Removes the rule and all of its alerts from the project.

Choose **shorten the effective period** when the rule has served its purpose for past data, **edit** when the threshold or condition needs tuning, and **delete** when the rule is no longer relevant to the project at all.

## Alerts and reports

Alerts on records included in a report are visible to the report reviewer. To resolve them before submitting a report:

1. Address the underlying data issue, or
2. Dismiss the alert with a reason that the reviewer will see.

Either path produces an audit-friendly record of how the issue was handled.