Triggers

A trigger binds a resource to a workflow. When a form is submitted, a webhook receives a request, or a schedule fires, the trigger starts the workflow with that event's payload.

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.