Skip to main content
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:
LocationWhat you see
Event drawerEvents 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 detailBatches 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.
ReportsAlerts 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

1

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
2

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.
3

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.
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. 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.
Choose shorten the effective period when the rule has served its purpose for past data, edit when the threshold or condition needs tuning, and archive 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.