Triggers

A workflow declares one or more triggers. Each trigger supplies a payload, which is normalised into typed workflow inputs before any step runs.

• Webhook — an authenticated endpoint per workflow. The payload is mapped to inputs by a declared schema; unmapped fields are available but not implicitly trusted.
• Monitoring alert — delivered by a connector, preserving asset, severity and trigger identity so correlation and maintenance-window suppression can apply.
• Ticket event — created, tagged or transitioned events from a connected service desk.
• Schedule — cron expressions with a declared timezone, used for maintenance campaigns, reconciliation and test rotations.
• API — an authenticated REST call with typed parameters, used when another system orchestrates StackHeal.
• Manual — a form generated from the workflow's input schema, for operator-initiated runs.

Scope binding

Every run is bound to a tenant, an environment and an asset set before the first step executes. Binding is resolved from the trigger payload through the rules you configure — never inferred by the interpretation layer. A payload that cannot be bound to exactly one tenant scope fails before any action runs.

Suppression

Triggers can be suppressed by maintenance windows, by tenant-level pauses, or by a repeat-run detector that escalates instead of re-running an action that has already run recently on the same asset.