Skip to main content

AutessaDB Triggers

Triggers turn AutessaDB tables into automation surfaces: when a row is inserted, updated, or deleted, a trigger can invoke a tool, an agent, or a multi-agent — or update another table — with the row's column values available as variables. Chain triggers across tables and you have a full processing pipeline, visible and editable right where the data lives.

What it's for​

  • React to data changes — send a welcome email when a signup row lands, kick off an agent when a document is uploaded, recalculate a rollup when a status flips.
  • Build pipelines without queues — a trigger on table A writes a row into table B, whose own trigger runs the next step. Each stage's inputs and outputs are ordinary rows you can inspect and correct.
  • Keep automation observable — every firing is recorded in the Trigger Execution History with the before/after row snapshot and the action's response.

Triggers are defined per table: open a table under AutessaDB → Tables and switch to its Triggers tab — what you can do there depends on your access level on the table (see below). Execution history has its own page at AutessaDB → Trigger Execution History.

Key concepts​

Anatomy of a trigger​

A trigger has four parts:

  1. Identity — a name, optional description, and an enabled/disabled switch.
  2. Event — fires on INSERT, UPDATE, or DELETE of rows in the table.
  3. Condition — a filter mode of Any Column (fire on every matching event) or Specified Columns with one or more column filters combined with AND/OR. Operators cover change detection (Changed, Became Null, Became Non-Null), value comparison (Equals, Not Equals, Is Null / Is Not Null), numeric comparisons, text matching (Contains, Starts With, Ends With), multi-select operators (Value Added, Value Removed, Contains Value), and boolean checks. Comparison values can be literals or references to other columns.
  4. Action — one of four types:
    • Invoke Tool — pick any tool you can access and map each of its arguments to a literal or a column reference.
    • Invoke Agent — pick an agent and compose its input prompt, e.g. Analyze this feedback: @@{feedback_text}; prompt template variables are filled the same way.
    • Invoke Multi-Agent — the same, but delegating to a manager; each firing starts a fresh, single-turn conversation.
    • Update AutessaDB — insert or update a row in a target table, mapping its column values from the source row.

Row variables​

Anywhere an action accepts a value, @@{column_name} inserts the row's current (new) value, and @@{old.column_name} inserts the previous value (available on UPDATE and DELETE). Typing @@ opens autocomplete over the table's columns. This is how a trigger passes data into its tool, agent prompt, or target table.

Key triggers on artifact columns rather than status flags where you can: "fire when transcript became non-null" is more robust than "fire when status equals transcribed", and it coexists cleanly with rows that users edit by hand.

Trigger chains as pipelines​

Because an Update AutessaDB action can write into another table — and tools, agents, and multi-agents can themselves write rows — trigger firings compose into multi-stage pipelines. A common shape: an intake table's INSERT trigger invokes a processing tool; the tool writes its result column back; a second trigger on that column becoming non-null runs the next step or copies the finished record to an output table.

Chains can get intricate, so a design-time impact analyzer is available: give it a table and an event type and it statically maps which triggers would match, which tables, tools, and agents the cascade could touch, and warns you about potential cycles in the trigger graph — nothing is executed.

Execution history​

The Trigger Execution History page shows every firing for a table, month by month: the event ID, trigger name, trigger type, the database event (INSERT/UPDATE/DELETE), the response status, and the timestamp. Three drill-downs are available per row:

  • Trigger Definition — a historical snapshot of the trigger as it was when it fired (flagged if the trigger has since been deleted).
  • Database Event — the row's before and after values, field by field.
  • Trigger Response — the action's outcome, including a link to the agent conversation for agent-invoking triggers.

How to create a trigger​

  1. Open the table and go to its Triggers tab, then create a new trigger.
  2. Name it (e.g. "Send Welcome Email") and pick the Trigger Type — Invoke Tool, Invoke Agent, or Update AutessaDB.
  3. Choose the Event (INSERT / UPDATE / DELETE) and the Filter Mode. For Specified Columns, add filters — for example transcript + Became Non-Null.
  4. Configure the action, mapping arguments or column values with @@{column} references.
  5. Save with Create Trigger. Triggers can be cloned, disabled, and re-enabled from the list at any time.

How to debug a trigger​

  1. Go to AutessaDB → Trigger Execution History and select the table and month.
  2. Find the firing — failed responses are badged red.
  3. Open the Database Event to confirm the row change looked as expected, then the Trigger Response to read the error or, for agent triggers, jump into the agent conversation.
  4. If the trigger definition itself was wrong, the Trigger Definition snapshot shows exactly what configuration fired.

Access levels​

Triggers don't have their own sharing — what you can do follows your access level on the table:

  • READ — view the table's triggers and their execution history.
  • PUBLISH (or ADMIN) — add a new trigger.
  • ADMIN — edit, delete, enable, or disable an existing trigger.