Trigger System
Lifecycle hooks on every insert, update and delete run your rules inside the write itself — so the automation lives where the data changes, not in an external tool watching from outside.
Illustrative UI only. Data and individuals shown are fictitious; any resemblance to real persons or data is coincidental.
Hooks on the full lifecycle
Insert, update, delete and restore each get a before and an after hook — ten in all. Delete hooks even know whether the delete is a soft archive or a hard removal, so one rule can treat them differently.
Rules that can say no
A rule can block a write outright, or attach errors to the specific fields that caused them — and it happens before anything reaches the database, not as a cleanup afterwards.
Knows exactly what changed
Handlers can ask which fields changed and what each one held before, without running extra queries. "Notify me when the status moves" is a one-line check, not a diffing exercise.
Scheduled work on the same rails
Recurring jobs are records, not deployments — schedules live as data, with a proper queue, retries and a dead-letter path behind them for the runs that fail.
Why we like this one
Automation bolted on from outside always arrives late — it reacts to a change that already happened, and when it fails, nobody's record knows. These rules run inside the same transaction as the write they respond to, so a rule that fails stops the write instead of leaving half of it behind. And rules layer: the platform ships a default, your industry blueprint can override it, and your own deployment can override that — the most specific rule always wins.
Book a demo ➝