Rules

Making the product do something by itself when a condition holds — and seeing what it has actually done about it.

Where you say what should happen automatically, and where you find out whether it is happening.

A rule is a condition over a record, asked at a named moment, with something that happens when it holds.

How to read the list

Every rule shows what it has actually done, because the two questions anybody has about a rule are the two a form cannot answer: is it doing anything? and would this change do what I think?

Figure	What it tells you
Matched	How often the rule has fired, and when it last did
Unevaluable	How often the server ran the rule and could not read it
Live and has never matched	Published, asked, and it has never once held

Unevaluable is the worst of the three. A rule with a mistake in a field name is not switched off and does not look broken — it simply never matches, and nothing announces that. The count is there so somebody finds out before the notification that stopped arriving is missed.

A rule that refuses a transition does not appear in these counts. Refusing rolls the whole attempt back, including the record of the refusal; the person trying to make the move is told at the time instead.

Show what it has decided opens the last twenty times the rule was asked, clause by clause, with what each one expected and what it actually found.

Writing one

1. Name it

   A code, a name, and a line saying what it is for.

2. Choose what it is about, and when it is asked

   The record type, and the moment — as a record moves, once it has moved, when a candidate is being considered for a job, and so on. Each moment carries a hint saying what it means.

3. Say when it applies

   The condition builder: groups combined with all of these must hold or any one of these is enough, with not where you need it, nested up to a few levels deep. Each clause is a field, a test and a value. The fields offered are the ones the record actually carries, and you can type your own.

   An empty condition is a rule that applies to every event of its kind. That is a real thing to want, so it is reachable rather than refused.

4. Say what happens

   One or more actions. Each says whether it runs immediately or runs in the background — that is decided by the kind of action, not chosen. A background action is queued, so it cannot fail the save that triggered it.

   A rule with no actions cannot be published.

5. Set the priority

   Rules are asked in priority order. Stop after this one matches ends the run for that record.

Record every time it is asked keeps a line for every evaluation rather than only the matches. Useful while working out why a rule is not firing, noisy afterwards.

Trying it before it is live

Try it against a real record runs the engine itself against the condition as it stands, on a record you name. Nothing is performed and nothing is written.

It comes back with the outcome, the reasoning clause by clause, and what the rule would do. This is not a second opinion computed by the screen — it is the same evaluator that will decide for real.

Save the rule once before testing it.

Saving is not publishing

Saving a rule does not put it live. Publishing does, and it is a separate button.

Editing a published rule returns it to draft with its version advanced. The decisions the rule has already recorded name the version that made them, so quietly changing what it says would leave every one of them describing a condition that was never asked.

Retire takes a live rule out of service and keeps its history.

Who can write rules

Rules change what the product does to records on its own, so writing one takes the workflow administration permission — System Administrator and Maintenance Administrator by default. Anyone without it sees a note saying so rather than an editor. See roles.

Guards on individual status changes are edited on the statuses and transitions screen, using the same condition builder.