Automation engine
Purpose
Recurring processes should not depend on individual people remembering them. The automation engine carries them out: when an event occurs it checks conditions and performs actions — possibly only after a wait.
The singular matters: there is exactly one such engine in the whole system. No module brings a second. Whoever has learned once how a rule is built can do it for every area — and there is no second place to look when something happened by itself.
Scope
- Triggers from system events, from recurring points in time, and from points relative to a date
on the record.
- Conditions as nested and/or trees rather than a flat list.
- Genuine waits: a rule with a delay blocks nothing; it rests and resumes by itself later.
- A dry run that shows what would happen without doing it.
- The origin is visible: shipped, contributed by a module, or created in-house.
- Templates that always create a new automation switched off — arming it is deliberate.
- The active state survives updates. What you switched off stays switched off.
Interplay
Automations use the same operations as the API and are subject to the same permissions. Their actions appear in traceability with Automation as the actor — cleanly separated from human ones. Sending runs through communication, not around it.
Limits
- Domain calculation engines are not rules. Dunning levels, recurring invoices, pricing rules or
retention periods are domain logic; they hook in through triggers and actions rather than being rebuilt as rule sets.
- An automation can do no more than its permissions allow.
- A rule without a dry run is a guess. The dry run exists because a badly built rule touches many
records quickly.