# 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`.

```yaml
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.

:::callout
**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.

```yaml
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](/en/docs/automation-subworkflows).

## Automation-Failure Trigger

Fires when a watched automation fails — composable failure handling, without per-automation notification config.

```yaml
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.

:::callout
**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](/en/docs/automation-retry-failure) for in-run recovery.
:::

## Related Pages

- [Triggers Overview](/en/docs/automation-triggers) — the nine trigger types at a glance.
- [Sub-Workflows](/en/docs/automation-subworkflows) — the `automation/call` and `automation/return` actions.
- [Retry & Failure](/en/docs/automation-retry-failure) — per-action retry before a run is declared failed.
- [Automation Runs](/en/docs/automation-runs) — inspecting, replaying and cancelling runs.
- [MCP Integration](/en/docs/mcp-integration) — how `aiAccess` exposes a manual automation to an agent.