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.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.
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. |
Triage an alert
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
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. This creates a new version, and historical results stay tied to the version that produced them.
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.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.
Reviewing rule activity
Open a rule from Project Settings → Data Rules to see its full evaluation history:- Alerted Records — every record that has matched the current version, with status (
fail,pass,dismissed), date range, tracking ID, and source. - Version selector — switch to a previous version to see the records it flagged. Historical versions are read-only; the banner reminds you to switch to the current version to make changes.
- Test rule — re-run the current expression against recent project data without saving anything new. Useful when you want to gauge whether a rule is still firing as expected.
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. This creates a new version; old alerts remain attached to the version that produced them.
- Archive the rule. Stops the rule, hides its alerts from records, and preserves its history for audit.
Alerts and reports
Alerts on records included in a report are visible to the report reviewer. To resolve them before submitting a report:- Address the underlying data issue, or
- Dismiss the alert with a reason that the reviewer will see.