Automation Center
Overview
Public
Automation Center
The ERPat Automation Center lets administrators build scheduled rules that approve routine work automatically — with a preview before anything changes, an Observe mode that mutates nothing, and a reason code recorded against every single record.
Guide version: r1
Module version: 0.3.3 Updated: 2026-09-04 Estimated time: 4 min 1 views
Introduction
Automation Center
Build scheduled rules that do the routine approving for you — after you have watched
them decide, and never before.
⚡ 1 cron job
◈ 5 screens
☑ 3 tables
⚿ 10 permissions
▤ v0.3.2
Every payroll period, somebody opens Attendance and clicks Approve a few
hundred times on records that were never in doubt. The Automation Center is where you
write down the rule you were applying in your head, watch it agree with you for a while,
and only then let it act.
⚠
Live mode changes real records. That is why it is not the default and not one
click away. An automation must first complete an
Observe run against the
same configuration, promotion needs a separate permission, and the first live run
is capped — to your
First live run limit, 50 by default. Read
Permissions, Authority & Scheduling before you
promote anything.
What it is — and what it is not
The Automation Center schedules, throttles, records and audits. It does not own
attendance, payroll, or employee data, and it contains no rule about any of them. Every
capability it offers is contributed by the module that owns those records: HumanResource
owns attendance, so HumanResource — not this module — decides what "eligible for
approval" means and performs the approval through the very same service the Approve
button calls.
✔
It does
Hold the schedule, claim the occurrence, freeze the configuration,
lease the run, feed candidates through in bounded chunks, stop at its caps, record an
outcome and a reason for every record, and write one audit entry per run.
✕
It does not
Know what an attendance record is. Decide what may be approved.
Write to a business table. Own a second scheduler. Outlive the module whose data it
acts on — switch that module off and its automations stop and ask for review.
How a decision gets made
Nothing here is magic, and nothing is hidden. A run walks the same three questions a
person walks, in the same order:
Which records are even candidates? The owning module's handler asks, bounded
by your lookback window, your settle delay, and your scope (departments, teams,
individuals — or everyone).
Do they pass your rules? The conditions you built in the wizard are evaluated
against pre-fetched values. A record that fails gets a reason code, not silence.
Should anything change? In Observe mode, no — the run reports what it
would have done and touches nothing. In Live mode it calls the owning
module's own service, attributed to the System actor, one record at a time.
????
Preview and Live are the same code. The preview in the builder and the run that
eventually acts share one evaluator, differing only in whether a decision is written.
A preview that could disagree with the run it predicts would be worse than no preview
at all — so there is deliberately no second code path.
Explore the guide
This guide serves two readers. If you are setting up and running automations, the first
three cards are your path. If you are a module developer adding a new kind of
automation, start at the Integration Contract.
Enable the module, run its migrations, grant the permissions, and
build your first automation in Observe mode.
The five-step wizard, previewing against real data, publishing,
promoting to Live, cloning, pausing, and reading a run.
The ten permissions, publisher authority, the System actor, how
scheduling actually works, and what to check when nothing runs.
For developers. How a module contributes an automation
type: the sidecar, the two interfaces, the rule engine, and the mutation rule.
For developers. Dispatch, claim, lease, chunk, finish — and
exactly which half of it is yours.
Every sidecar key with what actually reads it, the four code
vocabularies, the data model, routes and log events.
What was verified against the live source, what is not shipped
yet, and the deliberate compromises — named, so nobody "fixes" one.
"It says success but nothing changed", "my type does not appear",
"everything moved to Needs review" — and the glossary.
The module at a glance
| Module slug | automations — the setting is module_automations, off by default |
|---|
| Where it lives | Sidebar → Administration, between System Logs and Settings |
|---|
| Scheduler | ERPat's Advanced Cron runtime. Exactly ONE job: automation_dispatch, every minute, per tenant |
|---|
| Tables | automations, automation_runs, automation_run_items — tenant database only |
|---|
| Types available | Contributed by other modules. Today: Attendance Auto Decision, owned by HumanResource |
|---|
| Status | Milestones 1–3 shipped (engine, builder, Observe, Live, clone). M4 (operations UI, notifications, APIs) and M5 (hardening) pending — see Research & Gaps |
|---|
ℹ️
No types installed? The Automation Center still works and is still useful — run
history, past-run analytics and engine health all function with zero registered types.
It deliberately does not declare a hard dependency on any module, because that would
take the whole module offline instead of just the one unavailable type.
