Manual, Sub-Automation & Failure Triggers
Three triggers that no external event and no schedule starts: an operator deciding, another automation delegating, and a run failing.
Manual Trigger
Admin-initiated execution, via a button in the admin interface or POST /api/automations/{name}/trigger.
trigger:
type: manual
label: Sync inventory
requiredRole: admin
inputSchema: { warehouse: { type: string } }| Property | Description |
|---|---|
label |
Button label in the admin interface (e.g. Export Report). |
inputSchema |
JSON Schema describing the input fields supplied at trigger time. |
requiredRole |
Auth role required to trigger. Defaults to admin. |
Every property is optional. Input supplied at trigger time is read at {{trigger.input.*}} — not {{trigger.inputData}}, which does not resolve.
Manual is the only trigger eligible for aiAccess. An agent may invoke a manual automation over MCP precisely because it does not fire on its own: exposing a webhook or cron automation to a model would hand it a lever that also pulls itself. This is enforced at config decode, not merely advised.
Automation-Call Trigger
Marks an automation as callable by another, via the automation/call action — the basis of sub-workflow composition.
trigger:
type: automation-call
inputSchema: { customerId: { type: string } }| Property | Description |
|---|---|
inputSchema |
Expected input contract (JSON Schema-like). Omitted, any inputData from the caller is accepted. |
This is the trigger's only property. The callee reads what it was given at {{trigger.input.*}}, and can also see {{trigger.caller}} (the calling automation) and {{trigger.depth}} (how deep the chain currently is).
Depth matters: automation/call carries a maxDepth guard defaulting to 10, so a chain that accidentally calls itself is stopped rather than recursing until the process dies. Return values flow back through the automation/return action — see Sub-Workflows.
Automation-Failure Trigger
Fires when a watched automation fails — composable failure handling, without per-automation notification config.
trigger:
type: automation-failure
automations: [nightly-sync, billing-run]| Property | Description |
|---|---|
automations |
Automation names (kebab-case) to watch, at least one. Omit the key entirely to fire on any failure. |
Omitting automations and supplying an empty array are not the same thing: the empty array is rejected at config decode, while omission is the documented way to watch everything.
One automation with this trigger replaces a notification action duplicated across every workflow. Point it at the jobs whose silent failure would actually hurt — a nightly sync, a billing run — and have it post to the channel your team reads.
Failure reaction is not sub-workflow composition. automation/call invokes a target declaring an automation-call trigger and waits for a result. This trigger fires after a different automation has already failed, and cannot influence that run. See Retry & Failure for in-run recovery.
Related Pages
- Triggers Overview — the nine trigger types at a glance.
- Sub-Workflows — the
automation/callandautomation/returnactions. - Retry & Failure — per-action retry before a run is declared failed.
- Automation Runs — inspecting, replaying and cancelling runs.
- MCP Integration — how
aiAccessexposes a manual automation to an agent.
Last updated September 1, 2026
This documentation was written with AI, so errors or outdated content are possible. Sovrium is in beta. Contributions and corrections are welcome.