Rules

A rule is a named, reusable yes-or-no question about a record, such as "is this applicant under 18?" or "is this placement in a hospital setting?". Other parts of the platform ask a rule by its key instead of each carrying its own logic, so the answer is defined once, tested once and changed in one place.

Where to find it

Architect Panel → Automation:

Rules — build, check against real records, and publish the rules that decide who a control applies to

What asks a rule

Today the main user of rules is compliance checks: each requirement type can name a rule in its Applies When setting, and the check is asked only of records where that rule is true. A rule on its own does nothing until something names its key.

How a rule is built

The Rules screen edits a rule as one or more groups of conditions:

Within a group, every condition must be true ("All of these").
Across groups, any one group being true is enough ("...or all of these"). Add a group with Add an alternative group.

Each condition has three parts: a field, an operator and a value. The field is the field's row name on the datastore (as shown in its Fields list), not its friendly name. A rule with no conditions at all applies to everything.

The operators

= and !=: equal, not equal. Numbers compare as numbers; text must match exactly, including capitals.
>, >=, <, <=: work on numbers and on dates written as year-month-day (2026-09-01). Anything else cannot be compared.
contains and startswith: text tests that ignore capitals.
isset and notset: whether the field has a value at all. The value box is greyed out.
in and notin: on this screen these take a single value, so they behave like = and !=. To accept one of several values, put each in its own group.
between: cannot be saved from this screen. Use two conditions in one group instead, for example >= 14 and <= 17.

Three answers, not two

A rule answers match, do not or cannot be decided. "Cannot be decided" happens when the field is empty on that record, when the field name is not on the datastore at all, or when a value cannot be compared (text against a number, or a date not written year-month-day).

The rule does not decide what "cannot be decided" means: whatever asks it does. Compliance checks treat it as "yes, ask for this check", which is the safe reading for a safeguarding control. So a misspelt field in a rule behind a check does not let anybody through; it makes the check apply to everyone.

Creating a rule

Open Rules and click New rule.
Enter a Name people will recognise ("Parental consent applies") and a Key ("parental-consent-applies"). The key is what configuration refers to and never changes once saved; use lower-case letters, numbers, dashes and underscores.
Under When does this apply?, fill in the first condition. Use + condition to add more to the group, and × to remove one.
Check it against real records and save it as a draft, then publish it. See Checking and Publishing a Rule.

Rules the screen will not edit

A rule can be stored with "not" or with groups inside groups (for example, one supplied with a product). The screen shows such a rule as it is stored, with a notice that it is more deeply nested than the screen edits, and does not let you change it, because flattening it would change its meaning.

Worked example

A work-experience scheme needs parental consent only for applicants under 18. The architect creates a rule named "Parental consent applies" with the key parental-consent-applies and one condition: ageatstart < 18, where ageatstart is a number field on the applications datastore. A second scheme also wants consent for anyone with declared support needs, so a second group is added with supportneeds isset. The rule now matches anyone under 18, or anyone with support needs recorded.

Recommendations

Name rules as the question they answer, so the list reads as a set of decisions.
Choose keys carefully; they cannot be renamed.
Compare numbers and dates, not formatted text, and store dates year-month-day.
Remember dropdowns store an ID, so compare against the ID, not the label.
Always check a rule against real records before publishing it.