Skip to main content
The rule builder walks you through three steps: When the rule should fire, Then what happens, and a Preview of what it would flag. This guide covers that flow end to end, from opening Data Rules through to saving, then editing a rule afterwards.

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:
  1. The Trigger type you picked, shown as a chip. For a Batch Calculation rule, also select the model whose results the rule reads.
  2. 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.
  3. The Rule name, shown in the rules list and in audit history. Keep it brief and stable, even if you later edit the condition.
  4. 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.
Next stays disabled until the step has what it needs. Hover it to see which fields are missing.
Data Points rules apply across the whole project. Autocomplete offers every data point type that is captured on an event, and the data points that get flagged come from the condition itself. A calculated data point type, one a model computes, is not offered, and a condition naming one is rejected when you save. Test a computed value with a Batch Calculation rule.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:Substitute appears only on Data Points rules, and only when substitutions are enabled on your account. If you do not see it, the rule can still alert. See Substituting a value for what a correction does to the data.

Acting on the whole window

When the condition contains a windowed aggregate, a switch appears under the action. With the switch off, the rule acts on the most recent data point in the window, the one that made the condition true. With it on, the rule acts on the other data points in the window as well: an alert rule flags them, a substitute rule corrects them.The switch reads Flag the whole window or Correct the whole window. On a stuck-sensor condition, one that tests MIN = MAX over one data point and window, it reads Flag the whole run or Correct the whole run instead, where the run is the stretch of repeated values. The first data point of the run keeps its measured value, and the fill and trailing methods leave the run out when they look for a replacement, so the replacement is never the stuck value itself. See Catching a stuck sensor for the condition and why the first value is kept.Where the condition uses two windows, the rule acts only on the data points inside both.

If the action is Substitute

Name the value the rule corrects under When this rule fires, substitute. This is a single choice and it is required. The list offers the number data points your condition references, and picks for you when there is only one to pick, so a condition reading one number and one text value fills it in for you too.Then build the chain under Substitution methods. Methods are tried in order until one produces a value. Click Add substitution method to append one, click a row to configure it, and use Move up, Move down, and Remove step to arrange them.The Window control offers two kinds. Trailing is a span reaching back from the value being corrected: set how many, and a unit from seconds to years. Calendar is the value’s own period: set the unit, days to years, how many consecutive periods it covers, and how many periods back it starts. A calendar window one period back is the previous complete month, quarter or year, which is how you say “last month’s average” rather than “this month so far”.
The fill and trailing methods only draw on values carrying the same tracking ID as the one being corrected. On a project that sets a tracking ID per delivery or per ticket, that usually leaves nothing to draw on, so the rule raises an alert instead of correcting. If a substitute rule corrects nothing and you expected it to, check the tracking IDs on the events it reads.
The last row of the chain is always Flag as alert: if no method produces a value, the value is left as it is and an alert is raised. Adding a Constant changes that row to say the alert will not fire, because a constant always produces a value. Anything you place after a constant is struck through and marked as never running.Forward fill, backward fill and Constant drop out of the picker once used, since repeating one can only fail where it failed the first time. The other methods stay selectable because their settings change what they read, so a second Trailing average over the same window is only caught when you save.Optionally fill in If no method produces a value, alert with to word that alert yourself. Left blank, it states that the correction could not be applied.

Holding corrections for approval

Below the chain, Hold for approval decides whether the rule writes its corrections or proposes them. With it off, a correction is written as soon as a method produces a value. With it on, each match becomes a proposal: the data point keeps its measured value until someone approves or rejects it, and a data point with a proposal waiting cannot go into a new batch. See Approve corrections for deciding them.Turn it on for a rule you are still learning to trust, or where each replacement value should be signed off. A rule that corrects many data points raises as many proposals. It is off on every new rule.

If the action is Alert

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

On a substitute rule this step reads What this rule would correct, or What this rule would propose with Hold for approval on, and it shows which records the condition matches. It does not compute the replacement values; save the rule and read what it produced.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 the heading named above.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.
A condition using WITHIN previews the same result it will produce once saved. Windowed conditions are heavier to work out, so the sampling note above appears on a smaller project than it would for a rule without one. See Rule Expressions for the detail.The preview applies the same validation as saving, so a condition the preview accepts is one the rule builder will save.
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. On a substitute rule the confirmation says the values it corrects will be overwritten, or, with Hold for approval on, that matches become proposals and nothing changes until someone approves.Editing a saved substitute rule applies the new methods going forward. Values it already corrected keep the value they have; revert those from the data point if they need to change.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 the rule alerts or substitutes as its action says.

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, and so does changing the action, the substitution methods, or the whole-window switch. The same reset applies to each, so plan on re-triaging a rule’s alerts after any of these edits. Switching Hold for approval on or off does not save a new version. Switching it off withdraws every proposal still waiting on the rule: nobody approved them, so those data points keep their measured values and are not corrected unless you evaluate the period again from the rule’s Runs tab. The confirmation counts them before you commit.
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.

Stopping or deleting a rule