Rules
A rule pairs a single condition with one or more actions: when the condition is true, the actions run. Rules are the decision points inside a rule set.
Anatomy of a rule
Every rule has a name (up to 30 characters), an optional description, exactly one condition, and a set of actions.
| Part | Description |
|---|---|
| Condition | The boolean test. A rule uses either a shared condition or an inline condition — never both. See Conditions. |
| Actions | What runs on a match. A rule uses either shared action sets or an inline list of actions — never both. See Actions Overview. |
| Active dates | An optional effective/expiration window limiting when the rule is evaluated at all. Both bounds are optional. See Active dates. |
Shared or inline Referencing shared conditions and action sets lets several rules reuse the same logic; inline definitions keep a one-off rule self-contained. The editor enforces the either/or choice for you.
Evaluation order
When a rule set runs, it evaluates its rules in order (or shuffled, if the set randomizes order). For each rule, the engine resolves the condition against the current context. If the condition is true, the rule matches and its actions are scheduled.
The rule set's Max rules to match setting can stop evaluation early once enough rules have matched, and its rule sequence setting decides whether matched rules run sequentially or in parallel.
That describes the default single pass. When the rule set uses Inference, matching rules fire one at a time in salience order, and each firing re-evaluates only the rules that read whatever just changed — so a rule can match again after an earlier rule updates its inputs. Salience is a per-rule integer (default 0, range −10000 to 10000) set in the List-view rule editor or the decision-table per-rule settings overlay; it is ignored entirely unless inference is on.
What happens on a match
- The condition evaluates to true.
- The rule's actions are gathered — either the referenced action sets or the inline actions.
- The actions run in their configured order, or in a randomized order when the rule enables action randomization.
- Actions can read and write the shared context, so later rules and actions see the results. See Data & Transform Actions.
The action sequence within a rule can also be Sequential (default) or Parallel. Run actions sequentially when one action depends on a value an earlier action wrote to the context.
Active dates
A rule can carry an active date window — an effective date and an expiration date — that limits when the engine evaluates it at all. Use it to schedule a policy change ahead of time, or to retire a promotion on a fixed day, without having to remember to edit the rule set on the day itself.
| Field | Meaning | Left blank |
|---|---|---|
| Effective date | The rule starts being evaluated at this date and time, inclusive. | Active immediately — no start bound. |
| Expiration date | The rule stops being evaluated at this date and time, exclusive. | Never expires — no end bound. |
You can set either bound on its own, both, or neither. When both are set, the expiration must be later than the effective date; an inverted window is rejected when you save, because it would leave a rule that can never fire.
Outside its window a rule is skipped exactly like a disabled rule: its condition is never evaluated and its actions never run. Because the condition is never evaluated, an AI condition on an out-of-window rule costs nothing.
You pick the date and the time in your own time zone; the value is stored and compared in UTC. The editor shows the resulting UTC instant beneath the time field so you can confirm exactly what the engine will compare against.
Every run reads the clock once and judges every rule's window against that same instant, so a rule cannot expire partway through a run — including a long inference cascade.
Dates govern the rule, not the data The window controls when the rule is live. To test a date carried in your input — “the order was placed before 1 March” — use an ordinary condition clause on that context value instead.
Where to set them, and how they show up
- In the rule editor, under Active dates on the Details tab. A status line tells you whether the rule as edited is currently live, still scheduled, or already expired.
- In the decision table, in the row's settings overlay (the gear).
- In the rule list, a dated rule shows a small chip — Scheduled, Expired, or Dated for one that is live now but will expire. Hover it for the exact dates. The decision table shows the same state as a calendar icon on the row.
To exercise a dated rule on both sides of its window without editing it, give a test case a Run as of date.
Including and excluding rules
A rule takes effect simply by being part of a rule set. To stop a rule from firing without deleting it, turn it off with the Enabled toggle on its decision-table row — a disabled rule keeps all its logic but is skipped on every run. Give it an active date window instead when the change should happen on a date rather than right now. You can also remove the rule from the set, tighten its condition so it no longer matches, or gate it behind a context flag — for example a clause that checks an isEnabled context value — to switch behavior on or off per run.