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 ➝