Triggers and routing
The trigger decides when a run begins. Outcome routes decide what the graph does when a step passes, flags a problem, is rejected, or errors.
Triggers
Manual
Press Run from the saved workflow. Use it for ad hoc work and testing a new definition.
Label
Start a seeded run for an open backlog ticket carrying the configured label. The ticket becomes an entry input and the occurrence is claimed to avoid duplicate runs.
Schedule
Start from a cron expression. Fleet claims each occurrence exactly once and applies the same in-flight run cap as other triggers.
KPI
Check a bound KPI on a daily, weekly, monthly, or custom cadence. When the KPI needs attention, Fleet starts the intervention workflow with the KPI context attached.
One repository belongs to the workflow. It supplies the ticket system, working tree, and run scope.
Outcome vocabulary
| error | Available on every step. Unrouted errors fail the run. |
| pass / flag | Review outcomes. Pass continues; flag can route back for repair. |
| approved / rejected | Approval outcomes. Rejection can route back or end the run. |
Bounded fix loops
Develop → Review
↑ │
└─ flag ─┘ retry up to 2 times
│
└─ exhausted → NotifyRetry limits belong to the routed edge. When the limit is exhausted, the workflow can invoke another step—usually a notification or summary—before recording the failure. Review rounds receive their own previous flags so the loop converges on unresolved concerns.
Workflow-level failure handling
An optional failure handler catches an unrouted error or exhausted recovery path. Use it to prepare a failure summary or notify the operator. The handler does not convert the original run into success; it preserves the failure and the evidence around it.