Building & Running Automations

Building & Running Automations

Everything you do after the module is switched on: build a rule in the wizard, watch it decide against real records, publish it so it runs on a schedule, and — only once it has proved itself on your data — let it act. This page follows that order, because the product does.

The page: five tabs, five questions

Automation Center is one page (Sidebar → Administration). Switching tabs never reloads it; each tab is fetched the first time you open it and then cached, and the tab you were last on is remembered. Three of the five appear only if you hold their permission, so a colleague's screen may legitimately show fewer than yours.

The New automation button sits on the tab bar and shows only while Overview or Automations is active — it belongs to those two tabs, not to the page.

The builder: five steps

Everything about an automation is set in one modal wizard whose stepper you can click through in any order. The steps are guidance, not security: every value is revalidated server-side by the owning type's own handler, so skipping ahead cannot smuggle a bad configuration past a rule.

Step 1 — Type, title, description

The type dropdown lists only types that are currently available: one whose owning module is switched off does not appear, though Overview still lists it as registered-but-inactive. Today the one shipped type is attendance.auto_decision, contributed by HumanResource.

Title is required and is what every list, run row and audit entry will call this rule — write it so a colleague reading the log next quarter knows what it does. Description is optional free text. Changing the type clears your conditions, because condition fields come from the type's own catalogue and a rule written against attendance fields is meaningless under another type.

Step 2 — Action: what the rule does, and how carefully

Phase 1 is approve-only. There is no Reject anywhere in this module, because the attendance handler refuses any other action — an automation can move work forward, never backwards.

The builder rewrites the help text as you change the overtime policy:

Step 3 — Scope and rules

Employee scope is one picker holding teams and individual members, grouped with Teams first — a flat list buries a handful of teams under every employee in the company. Search matches inside both groups. A token that no longer resolves (a deleted member, a removed team) is kept in raw form rather than quietly disappearing, because silently dropping it would rewrite your scope on the next save without you ever seeing it go.

Conditions are rows of field · operator · value, and a record must satisfy every one — they are ANDed. Anything that fails is left pending with RULE_NOT_MET, never silently ignored. Fields come from the selected type; for attendance they include log type, worked minutes, record age in hours, whether a schedule exists, whether existing overtime is present, whether the payroll date is locked, whether a schedule-change request is pending, and department / establishment membership. Choosing a field narrows the operators to the ones it supports, and the unary IS_TRUE / IS_FALSE hide the value box because they take none.

Step 4 — Schedule and safety

Step 5 — Review and preview

The Review pane reads the configuration back before anything is written: title, type, lookback, settle delay, overtime policy, schedule with its timezone, scope as labels (not raw tokens), and the number of conditions. It exists so you can catch the scope you forgot to narrow.

Previewing against real data

Run preview evaluates your unsaved configuration against your real records and reports what it would do. It changes nothing, needs no publish, and runs the same handler, candidate provider and rule evaluator a real run does — there is deliberately no second code path, because a preview that could disagree with the run it predicts would be worse than no preview at all.

340 matching record(s). In this sample of 250: 214 would be acted on, 36 left for review.

12 record(s) already have overtime recorded. With this overtime setting,
a live run would reset those hours to zero.

NOT_YET_SETTLED: 21
OVERTIME_PRESENT: 12
RULE_NOT_MET: 3

Saving — always a draft

Save writes a draft in Observe mode, whatever else you did in the wizard. It never schedules anything and never grants the rule the ability to act; each save of an existing automation increments its revision.

Publishing in Observe

Publish (Observe) in the row's action menu turns a draft into a scheduled rule: status active, next occurrence computed from your expression and timezone, and you recorded as the publisher — the authority its runs are checked against from then on. Needs automations_publish.

From this moment the automation runs on its schedule and changes nothing. It evaluates records, records an outcome and a reason for each, and files a run you can read. That is the whole point of the mode.

The Observe period — what to compare

There is no fixed length. Observe answers "would I have made these same decisions?", so run it long enough to cover the variation your data actually has — a payroll cutoff, a holiday, a week with a night shift in it. For each run:

Promoting to Live

Switch to Live mode appears on an active automation still in Observe, and it is the only action in this module that asks you to confirm. Four conditions must all hold, and the refusal names the one that failed:

The first live run is capped

An Observe run proves the rule selects the right records. It cannot prove the approvals are right, because nothing was approved. So the first run that actually changes records — the one nobody has seen the results of — is bounded, and a mistake that survived Observe costs a reviewable handful instead of a thousand records. Once one live run has completed, the normal ceiling applies.

Switching back to Observe

Switch back to Observe is always available on a live automation, needs no confirmation, and needs no go-live permission — only automations_update. Demotion is always safe, so it requires no evidence. Publishing and changing mode are separate actions because they answer separate questions: publish asks should this run on a schedule?, mode asks should it be allowed to change records? — and the second must stay reversible, so an operator watching a live run behave badly can stop it acting without archiving the rule and losing its configuration. The two directions are two menu entries, never a toggle, so the menu always states what will happen rather than what is currently true.

Pause, resume, archive

Clone — and exactly what it resets

Cloning builds a variant — same rules, different department; same schedule, different cutoff — without retyping a five-step wizard. It is offered on every status, archived included, and gated on automations_create, because creating is what it does. The copy carries the configuration and gets a title with a Copy suffix. What it deliberately does not inherit is the whole design — each reset is a way this could otherwise go wrong:

Runs and run items are not copied — they belong to the source. Because the copy has no completed run of its own, it must serve its own Observe period before it can be promoted, exactly like a rule built from scratch. The audit trail records the clone as a creation and names the source, so the log answers "where did this rule come from?".

Run Now

Run now queues an occurrence outside the schedule. It is offered on active automations and needs automations_run_now. It is not a shortcut past anything: the run is created as queued, marked as manually triggered, and goes through the normal executor path in the automation's current mode — an Observe automation still observes. The confirmation says so plainly: it "starts on the next dispatcher tick", within a minute, not instantly.

Reading a run

Open any row in Runs & Logs with the magnifier. The detail runs top-down, from the summary to the individual records.

The reason codes you will see

These come from the attendance type's handler, in the order it applies them. The first four are its own mandatory baseline, checked before your conditions.

What a healthy run looks like

Next: who may do each of these, whose authority a live run acts with, and how the schedule actually reaches the engine — Permissions, Authority & Scheduling.