Automation Rules

Rules and quotas both answer questions about something a person is trying to do: may this job queue?, has this person used their allowance? Automation rules answer a different question: what should Pluraprint do, unprompted, because something became true?

An automation rule has three parts:

• A trigger: the moment Pluraprint notices something. “A print’s outcome was confirmed”, for example.
• A condition: which of those moments this rule cares about, written with the same visual builder the requirements rules use.
• One or more effects: what happens as a result.

Open Admin in the sidebar, then choose Automation. Viewing needs the same permission as viewing rules; creating, editing and deleting need the matching rule permissions (see Roles & Permissions).

The editor, step by step#

A rule is written the way it reads, and the editor is four tabs in that order:

• When: step 1 picks what starts the rule, step 2 narrows it to the cases you mean. Both are optional to finish, but nothing else can be filled in until the trigger is chosen. It decides what there is to filter on and what the rule is able to do.
• Then: what happens. Add as many actions as you like; they all run, in the order shown.
• Test: run the rule against the data you have right now without applying anything, and, for a saved rule, see everything it has already done.
• Settings: the description, which site it applies to, list order, and the two switches covered below.

The rule’s name is the title at the top of the page: type over it. The line under it restates the whole rule in one sentence as you build it, and while anything essential is still missing it lists what is left instead; each item is a link to the step that fixes it, which is also why Save is unavailable until they are gone.

Each of the three choices: the trigger, a filter’s field, and an action, opens a dialog listing what is available with a description of each, rather than a dropdown of bare names.

Triggers that run on a schedule#

Most triggers are moments: something happens, and the rule fires once for the thing it happened to.

Some are not. “A print has been waiting to be collected” is not a moment, there is no instant at which a print becomes three weeks old. It is a standing question, asked of everything that is waiting, and somebody has to decide how often to ask it.

So a scheduled trigger carries its own setting, shown directly beneath the trigger once it is chosen: Check every ___ hours. A trigger marked runs over and over on a schedule in the picker is one of these, and the rules list shows each one’s cadence beside its trigger.

The schedule belongs to the rule, not to Pluraprint. Two rules on the same trigger can run at different rates: chase the owner every 12 hours, clear out what is left once a month, and the answer to when will this run? is on the same screen as the rule rather than buried in a settings page.

Checking more often makes a rule act sooner. It never makes it act more than once; see below.

Every matching rule fires#

Automation rules are evaluated as a set, exactly like requirements rules and unlike a first-match list. Every rule whose condition is true contributes its effects.

That matters as soon as you write a ladder of escalating responses. “Notify after two weeks” and “restrict after four weeks” are two rules, and at four weeks both are true. Because every match fires, the person still gets the notification they were owed: a first-match list would silently drop it the moment the second rule started matching.

Priority on an automation rule is display order only. It never decides which rule wins, because they do not compete.

Each effect happens once#

Every effect an automation rule applies is recorded against the subject it applied to. Pluraprint checks that record before acting, so:

• A rule evaluated on a schedule notifies someone once, not once an hour.
• Editing a rule’s wording does not re-send anything that already went out.
• Two Pluraprint processes running at the same moment cannot both apply the same effect.

The record is also the answer to “why does this person have that role?”, months later, and the handle for undoing it.

Only a definite match acts#

Conditions are evaluated with the same three-valued logic as requirements rules: a condition that depends on something Pluraprint does not know evaluates to unknown rather than true or false.

A requirements rule can afford to surface an unknown and wait for someone to resolve it. Automation cannot. It acts on people’s behalf with nobody watching, so an unknown means do nothing. If a rule is not firing when you expect it to, check whether the field it asks about is actually populated for that subject.

Effects that change someone’s access wait for a person#

Effects are marked sensitive when they change what somebody is allowed to do: adding or removing a role, for example. A sensitive effect does not apply itself. It records a request and waits, and the requests appear under Waiting for approval at the top of the Automation page, where someone can:

• Approve it, which applies the effect and records who decided;
• Decline it, which never asks about that subject again.

A rule can opt out of that with Skip approval for changes to people’s access, on the rule’s Settings tab. It only appears once the rule has an action that needs it. The default is deliberate: a rule that restricts people should be watched before it is trusted.

Anything already applied that can be undone shows an Undo action on the same list.

Try a rule before it bites anyone#

Two things make a new rule safe to introduce.

The dry run. In the editor, the Test tab evaluates the rule you are looking at against the subjects that exist right now and reports what it would do: how many were examined, how many matched, and which effects would run on which subjects. Nothing is applied and nothing is recorded. Some triggers only fire as events happen and have nothing standing still to evaluate against; the page says so rather than reporting a misleading zero.

Test mode. A rule with Test mode switched on, under Settings, is evaluated normally and never applies anything. It is the honest way to watch a new policy for a week before letting it act.

Sites#

Like rules and quotas, an automation rule is either global or scoped to one site. A site-scoped rule only ever acts on subjects belonging to that site.

What gets recorded#

Every automation action is written to the tamper-evident audit log: the rule, the subject, the effect, and who approved it where a person did. The Activity list on a rule’s Test tab shows the same history in readable form, including anything that failed and why.

A failed effect is retried the next time its trigger fires: a queue being briefly unavailable should not permanently cancel a notification, so an effect that keeps failing stays visible with its error rather than disappearing.