Loading

Checking and Publishing a Rule

A mistyped rule does not raise an error: it silently matches nobody, or everybody. The Rules screen therefore lets you run a draft against real records before you save it, and keeps every version, so a rule is checked before anything relies on it and can always be traced back afterwards.

Where to find it

Architect Panel → Automation:

  • Rules — the list of rules, the editor, its preview and the Versions card

Checking a rule against real records

The Check it before you save it card sits under the conditions.

  1. In Datastore, type the name of the datastore the rule will be asked about, for example applications.
  2. Leave Field prefix blank for a rule used by compliance checks, which name fields directly.
  3. Click Preview. The screen shows "Checking..." and then a line such as "Against 1,240 records: 212 match, 1,006 do not, 22 cannot be decided."

Read the extra notes it adds:

  • "Nothing matches." Almost always a field name that is not on this datastore, or a dropdown that stores an ID being compared with text.
  • "Most records cannot be decided." At least half the records have no usable value. Remember that a compliance check treats "cannot be decided" as "ask for the check", so all of those records will be asked.
  • "Not on that datastore: ..." lists field names in the rule that the datastore does not have. Fix the spelling, using the row name from the Fields list.

The preview reads up to 2,000 records and does not filter by organisation, so on a very large or multi-tenant datastore treat the numbers as a sample.

Saving and publishing

  1. Click Save as draft. The message reads "Saved as draft version N. It is not in use until it is published." Saving never changes what is in use.
  2. Go back with ← All rules and click Open on the rule. The Versions card lists every version with a published or draft badge.
  3. Click Publish beside the version you want and confirm. From then on, anything asking for that key gets this version. Verdicts already recorded keep the version they were made under.

Every save writes a new version; nothing is edited in place. To change a published rule, open it, change the conditions, save a new draft and publish that. The list's In use column shows the published version (for example "v3"), or "draft only" for a rule that has never been published.

Platform rules and your own

On a multi-tenant system a rule can exist at platform level (shared by every organisation) and as an organisation's own version with the same key. When an organisation has its own published version, that one wins. You can only save and publish your own organisation's versions; trying to publish a platform version reports "No such ruleset version."

What goes wrong and how to tell

  • "Asked for but not here." at the foot of the list: a compliance check names a rule key that does not exist. Create the rule with exactly that key.
  • A draft-only rule is treated as missing. Until a version is published, anything asking for the key gets "cannot be decided", so a compliance check behind it is asked of everyone.
  • "This rule is not valid": usually a between condition, which this screen cannot save. Use two conditions instead.
  • "A key is required" or "Give it a name somebody else will recognise.": fill in Key and Name.
  • An error window and the preview stuck on "Checking...": the datastore name was wrong ("There is no datastore called ..."). Correct it and click Preview again.
  • Edits made outside this screen: the Rulesets datastore is also visible under Data → Datastores, but editing a row there bypasses every check described here. Use the Rules screen.

Worked example

An architect writes "Parental consent applies" as ageatstart < 18 and previews it against applications: "Against 640 records: 0 match, 0 do not, 640 cannot be decided", with "Not on that datastore: ageatstart". The field is actually called agestart. They correct it and preview again: 96 match, 538 do not, 6 cannot be decided. The six have no start date yet, and since the consent check will be asked of them anyway, that is acceptable. They save version 1 as a draft, open the rule and publish it.

Recommendations

  • Preview every draft, even a one-line change.
  • Investigate a large "cannot be decided" count before publishing.
  • Publish deliberately; a saved draft does nothing until then.
  • Keep rule edits on the Rules screen, never in the raw datastore.