Skip to main content

Making things happen automatically

Choose between AutessaDB triggers, scheduled events, and custom webhooks — the three ways to run work without a person pressing a button.

The decision: something should run on its own. What makes it fire — a row changing, a clock, or an outside system calling in?

The systems​

  • AutessaDB triggers (autessa.autessadb.trigger.*) — fire per row when a table row is inserted, updated, or deleted. A trigger runs a tool, an agent, a manager, or a write to another table. User-editable, and the natural way to build processing chains: a write into table A fires a trigger that writes table B, whose trigger writes table C.
  • Scheduled events (autessa.scheduledEvents.*) — fire on a clock: a recurring rate, a cron expression, or a one-time future moment. Each event invokes an agent, executes a tool, or writes AutessaDB rows. This is for "every Monday", "in 24 hours", "nightly".
  • Custom webhooks (autessa.customWebhooks.*) — fire on an inbound event: an outside system calls the webhook's public URL, and that runs a tool, agent, manager, or AutessaDB operation. The webhook can transform the incoming payload before it runs.

Decision rules​

  1. Reacting to your own data changing → a trigger. If the cue is "a row was added/edited", add a trigger with autessa.autessadb.trigger.add. Key the trigger on the artifact columns that mean "ready to process", not on a status flag you flip by hand.
  2. Reacting to time → a scheduled event. If the cue is a date or a cadence, use autessa.scheduledEvents.create. Toggle it on/off with autessa.scheduledEvents.toggle rather than deleting and recreating.
  3. Reacting to the outside world → a custom webhook. If a third-party system needs to push an event in, create one with autessa.customWebhooks.create (its API key is returned exactly once — capture it then).
  4. Chain steps as triggers, not queues. When a feature's records live in AutessaDB, a multi-step pipeline is a chain of triggers on the tables, each step firing the next — not a set of background queues.
  5. Retention belongs in triggers too. To expire old rows, drive deletion from a trigger or a scheduled event that removes rows past their age, keeping the cleanup user-visible and user-editable rather than hidden in backend code.

Worked examples​

A. Enrich every new lead. A trigger on the leads table (autessa.autessadb.trigger.add, on INSERT) runs a tool that fills in company data and writes it back to the same row.

B. Weekly digest. A scheduled event (autessa.scheduledEvents.create, cron for Monday 09:00) executes a tool that queries the week's rows with autessa.autessadb.query.query and emails a summary.

C. Inbound form submissions. A custom webhook (autessa.customWebhooks.create) receives a third-party form POST, transforms it, and inserts a row via the AutessaDB operation it runs — which then fires the enrichment trigger from example A, chaining the two.

See also​

  • data-placement — where the rows these automations read and write should live.
  • agents-tools-managers — what a trigger, event, or webhook actually invokes.