Triggers

What it is. The glue between the outside world and a workflow. A trigger binds a resource to a workflow; when the resource fires, the workflow runs with the payload as input.

Use it when a form submission, webhook call, or schedule should start a run.

Works with resources (the three sources) and workflows (the target).

For defining resources, see Resources. For defining workflows, see Workflows.

Syntax

trigger name {
  resourceType:resourceName -> workflowName
  enabled: true
}

Resource types: form, webhook, schedule.

Fields

Examples

Form trigger:

trigger on_contact {
  form:contact_form -> process_form
  enabled: true
}

Webhook trigger:

trigger on_webhook {
  webhook:inbound -> handle_webhook
  enabled: true
}

Schedule trigger:

trigger daily_run {
  schedule:daily_report -> generate_report
  enabled: true
}

What happens when a trigger fires

• The payload lands on context.nodes.root.input, validated against the root's inputSchema. context.meta.triggerType is "form", "webhook", or "schedule".
• One inbound event can start multiple runs: every enabled trigger that matches the resource fires, each starting its own execution.
• If the project is over its plan quota, or a required vendor key is missing, the run is recorded in a held state instead of executing. Resolve the hold to let future events run.
• Only triggers from the project's active deployment fire. Redeploying supersedes the previous deployment's triggers; in-flight runs finish on their original definition.

Rules

• The referenced resource (form, webhook, schedule) must be declared somewhere in the project. Declarations resolve by name across all .swirls files.
• The referenced workflow must be defined.
• A workflow can have multiple triggers (for example, triggered by both a form and a schedule).
• A resource can fan out to multiple workflows through multiple triggers.
• Trigger names must be unique.