Skip to main content
A trigger runs a set of flows when your application deploys, or on a schedule. Triggers belong to the workspace, so one trigger can cover staging, production and every preview environment. You create and edit triggers on the workspace’s triggers page, or through the public API and CLI. The triggers page runs flows by tag or as a Smart Smoke Suite. Naming flows one by one takes the API or CLI.

​
Trigger kinds

  • Deployment — fires when your pipeline notifies QA Wolf of a successful deploy that matches the trigger’s conditions. The flows run against that deploy. See PR testing and the deployment testing guides for how the notification reaches QA Wolf.
  • Schedule — fires hourly, daily or weekly in one environment, and an hourly or daily schedule can be restricted to chosen days of the week. Needs nothing from your pipeline.

​
What a trigger runs

  • A tag — every flow carrying it. Flows tagged later join automatically.
  • Named flows — a fixed set.
  • A Smart Smoke Suite, labeled Generative suite on the triggers page — flows QA Wolf selects from the pull request behind the deploy. Deployment triggers only, and only for deploys tied to a pull request. See PR testing.
Give preview deploys their own trigger rather than widening the one that covers staging. A pull request rarely needs everything staging runs, and a Smart Smoke Suite skips every deploy that has no pull request.

​
Pausing

A paused trigger never fires. Resuming brings back the same configuration. A resumed schedule picks up at its next slot, and slots it missed while paused don’t run.

​
Reference

  • Trigger fields — conditions, schedule and action fields.
  • Deployments — how QA Wolf reads a deployment, and the verdict it records for each trigger.
Older workspaces may still run legacy triggers, which attach to a single environment. See Migrate from legacy triggers to move them.
Last modified on October 26, 2026