Before you start
You need:- Write access to the project’s Data Rules. Ask an admin if the Add data rule button is greyed out.
- A clear sense of the measurement or calculation you want to validate, and the threshold or pattern that defines a problem.
Step-by-step
1
Open Data Rules
Navigate to Project Settings → Data Rules. The page lists every rule configured for the project, with what it runs on, its status, and the dates it applies to.Click Add data rule to start.
2
Choose what the rule checks
The New data rule screen offers two kinds of rule:
Picking one starts the wizard. You can come back to this choice from the Change link on the When step at any point before saving. Re-picking the same kind keeps your work; switching to the other one clears the condition, because the two author against different variables.
3
When: what the rule looks for
This step holds four things, in order:
- The Trigger type you picked, shown as a chip. For a Batch Calculation rule, also select the model whose results the rule reads.
-
The Condition. Type
{{to open autocomplete and pick a data point or model node. When the condition evaluates to true on a record, that record is flagged.See Rule Expressions for the full language reference. - The Rule name, shown in the rules list and in audit history. Keep it brief and stable, even if you later edit the condition.
- The Effective period. Choose Always active, or Fixed range to set an Effective from and Effective to. Saving evaluates every matching record inside the period, both historical and going forward. Records outside it are not touched.
Data Points rules apply across the whole project. Autocomplete offers every non-static data point type in the project, and the data points that get flagged come from the condition itself.One rule reads a single event type. Autocomplete does not enforce that, so a condition can be written across two event types and is rejected when you save, naming the event types it spans.
4
Then: what happens
Pick the Action. Alert flags the record and changes no values.Then decide which data point the alert attaches to, under When this rule fires, flag:
Reach for Specific data points when a rule reads one value but is really about another. A rule like
{{data-point.vent_1_speed}} > 90 OR {{data-point.vent_2_speed}} > 90 covers two pieces of equipment, so flagging both when only the first breached sends whoever triages the alert to the wrong place.You can only pick data points the condition already references. If you later edit the condition and drop one, it is removed from the selection too. Batch Calculation rules do not use this control.Finally, write the Alert message, the explanation shown on each flagged record. It is generated from the condition by default; edit it to read naturally for the people triaging alerts.The rule name and condition sit above this step read-only. Edit expression takes you back to the When step to change the condition.5
Preview: what it would flag
The preview stays empty until you click Validate. Validating checks that the condition parses and that every variable resolves, then runs the rule against the project’s recent data under What this rule would flag.A preview covers the last 90 days unless you give it a range of your own, and a wider range is honoured when you do.Read the result before saving:
- Matches listed. Check they are the records you expected. Unexpected matches mean the condition is too broad.
- Nothing matches yet. The rule is valid and will run on new data as it arrives; nothing in the window matches it. A range filter appears with this result, so widen the window there, or adjust the condition, to see historical matches.
- A sampling note. On projects with a lot of events the preview covers only the most recent ones. Save the rule to evaluate the full history.
WITHIN is the exception: the preview cannot evaluate a windowed aggregate and reads it against an empty set, so COUNT previews as 0 with nothing on screen saying so. Use the preview to check the rest of the condition, and expect the window itself to run only once the rule is saved. See Rule Expressions for the detail.6
Save the rule
Click Save. Mangrove confirms that saving will evaluate everything the rule matches, then evaluates every matching record inside the effective period.You land on the rule detail page, showing its status, effective period, and the records found during evaluation. The rule is live: every new data point or batch generation inside the effective period runs the condition and raises an alert if it matches.
How rules appear in the list
The Runs on column shows what each rule binds to:Data Points, or Batch Calculation with the model name.
Editing a rule
Open a rule from the Data Rules list and click Edit. Editing uses a single form rather than the wizard, with the same fields in the same order. Changing the condition saves a new version and re-evaluates matching records inside the effective period. The new version’s results replace the rule’s existing alerts, so earlier alerts, including any you dismissed, are reset. Changing the effective dates saves a new version too, so the same reset applies. Plan on re-triaging a rule’s alerts after either kind of edit.Variables in an alert message render as the configured data point type name. The message is stored when you save, so this applies to rules created or re-saved from now on. Existing rules keep the message they were saved with.