Work that happens without anyone asking

An agent someone has to open is a tool. An agent that runs at 8am every weekday, or the moment a Stripe payment fails, or whenever your own product calls it - that is staff. Triggers are how you get there.

Create a trigger in a domain, subscribe the agents that should answer it, and every firing is recorded with the sessions it started.

Permissions and session ownership

All domain members can inspect triggers. Operators, Editors and Owners can create, edit, bind and manage them, including schedule catch-up batches. Organization roles alone do not grant these domain actions.

The trigger's owner is recorded on new sessions separately from their executing actor. A Viewer who owns a trigger can participate in its sessions while remaining a domain member; this does not grant permission to edit the trigger. Other Viewers can inspect those sessions, and Operators, Editors and Owners can participate. Personal API keys act as their authenticated owner. See Roles and permissions.

Create a trigger

Open Triggers and select New trigger. Choose a Domain, enter a unique Name, and choose Schedule, API, or Event under Type.

For a schedule, enter a five-field Cron expression. Saving a changed expression recomputes the next run immediately. For an API trigger, create the trigger, then use Triggers → API keys → New key when an external system needs a key. Copy a new key when it is shown; the screen does not reveal it again.

For an event trigger, choose the connected integration and one of its native event types. You may add one exact gate over a declared event field. The integration's Events tab opens this same drawer with the integration, connection, and event type preselected.

Subscribe an agent or flow

Open an Agent and select Triggers, or open a Flow and select its Trigger node. Select the trigger and save. You can also choose New trigger inside the Trigger drawer itself; its domain is already fixed.

Anything may subscribe; whether a firing can actually run it is decided at the firing, per integration, and recorded in the trigger's run history rather than refused when you save. Team-account and Platform connections are always safe unattended. Two identities are not, and each has its own recorded reason:

• An API caller binding set to Fail the run (credential required) - nobody is present to supply a token. Its firings are skipped as integration_not_unattended. Set it to Fall back to the domain, or to the team account, and it fires normally.
• A binding at The person using it - the firing runs as the person who created the trigger, so it is skipped as person_unavailable once they are no longer an active member, have not signed in, or the domain's door is shut. Anyone who manages the domain's triggers can create one, and it is that creator the agent then acts as - so create the trigger as the person whose account the work should run on.

See Identity.

For a Flow, declare its start fields under Inputs this flow needs to start. In the inline New trigger drawer, provide Input (JSON) to pass the same input on every firing.

Review or stop firing

Open Triggers, choose a trigger, and inspect its firing history. Each result links to the session it started and shows the run outcome or recorded error. Use the trigger’s action menu to Disable or Enable it. A disabled trigger remains configured but does not fire.

Trigger Run history uses these statuses:

Status	Meaning
succeeded	Every subscribed agent and flow started.
refused	The platform deliberately declined every start, for example because the subscriber was at capacity. This is not an agent or flow failure.
failed	The firing could not start work: its acting user was no longer valid, or every subscriber start failed.
partial	Subscribers produced more than one outcome: some started, were refused, or failed.
skipped	Nothing was attempted: no subscribers, a scheduled firing belonging to a suspended organization, or every subscriber skipped for a recorded per-binding reason such as integration_not_unattended or person_unavailable.
pending	The firing intent was recorded, but its outcome was never finalized.

A schedule that could not fire on time - the platform was down, or a backlog ran past two minutes - parks its missed occurrences as a catch-up batch on the trigger's Approvals tab rather than firing them late on its own. Anyone who manages the domain's triggers approves all, a range or the first of them, or discards the rest; the trigger must be active. Re-enabling a disabled schedule never backfires missed runs. See How approvals are layered.

The interface presents a pending run older than one hour as Interrupted before completion. Interrupted is a read-time presentation, not a trigger_runs status or database value. The row remains pending; direct queries of trigger_runs will never return interrupted.

API keys

An API trigger needs a key before an outside system can fire it. Triggers → API keys is where you mint, name, and revoke them.

Copy a new key when it is shown - it is never displayed again. Revoking a key takes effect immediately.

Tips

If subscription is refused, change every credential-required API caller binding to fall back to the team account, or remove the incompatible integration step. If static input is rejected, enter a valid JSON object that matches the Flow’s declared inputs. If an API call fails, inspect the trigger’s firing history. See Troubleshooting.