Database triggers

By the end of this page you will have set up a trigger that runs an agent whenever a row in one of your tables changes, and know how to test and review it.

Prerequisites

Admin role.
A deployment with at least one agent. See Managing agents.
A table in your project’s data whose changes should start the agent.

What a database trigger is

A trigger runs one of a deployment’s agents automatically in response to a row change — an insert, update, or delete — in a table you choose. Where a schedule fires on the clock, a trigger fires on data.

A trigger has two halves:

When — the table, the operation, and optional conditions that must match.
Then — the agent to run, and how the changed row is passed to it.

A typical example: whenever an order’s status changes, run a Task Agent that handles the next step.

The Triggers tab

Open a deployment and select Triggers. Each rule shows its table, the operation it watches, the agent it runs, its conditions, and stats — when it last fired, how many times it has run, and its success rate.

Triggers tab listing a rule with its table, operation, target agent, conditions, and execution stats

Creating a trigger

Set the “when”

Click to add a rule. Choose the table to watch and the operation: Insert, Update, Delete, or Insert or update.

Add conditions

Narrow when the rule fires with filter conditions on the row’s columns. Operators include equals and comparisons, IN / NOT IN, CONTAINS, IS NULL / IS NOT NULL, and CHANGED — which fires only when a column’s value actually changes. Combine conditions with AND / OR.

For an order-status example, watch Update on the orders table with the condition status CHANGED.

Create trigger dialog: table and operation on the left, a status CHANGED condition, and the target agent on the right

Choose the agent and map the row

Pick the agent to run — an AI Agent, Task Agent, or multi-agent system in the deployment — and choose how the changed row reaches it:

Full Row JSON — the whole row as JSON.
Selected Columns — only the columns you pick.
Prompt Template — a message with {{column}} placeholders filled from the row.

Set limits and save

Optionally cap how often the rule can fire (a per-minute limit and a debounce window), then save. The rule appears on the Triggers tab.

Testing a trigger

Use a rule’s Test action to run it against sample row data without changing real data — a quick way to confirm the agent receives what you expect and behaves correctly before you rely on live changes.

Reviewing what fired

Open a rule’s View History to see its executions — each with the run it dispatched, its status, and the row that triggered it.

Trigger Evaluation History panel listing dispatched executions, each with a run id and the row that fired it

From a rule’s actions you can also Pause / Resume, Edit, or Delete it.

💡

Pause a rule before a bulk data change you don’t want to react to, then resume it afterward.

Common issues

The agent isn’t selectable — only agents in this deployment can be a target. Add it first.
The rule isn’t firing — confirm it’s not paused, the operation matches (an update isn’t an insert), and the conditions actually match the change. Use Test to check the agent path independently.
It fires too often — add a CHANGED condition so it reacts only to real value changes, or set a per-minute limit and debounce.