Skip to main content

Triggers: Overview

A trigger decides when a workflow runs and what its initial payload is. Every workflow has exactly one.

Built-in triggers

TriggerTypeFires when
Manual@wf::trigger.manualYou call it directly — Workflow::run()/dispatch(), or php artisan workflow:run.
Webhook@wf::trigger.webhookAn HTTP request hits the workflow's generated URL.
Schedule@wf::trigger.scheduleA cron expression matches, via Laravel's scheduler.
Model@wf::trigger.modelAn Eloquent model fires a lifecycle event (created, updated, etc.).

All four are cliSupported, so all four are available in workflow:build.

How a trigger fires

Every path that starts an execution — the Workflow facade's run()/dispatch(), or a trigger firing on its own (a webhook request, a schedule tick, a model event) — ultimately calls the trigger's handle(), which returns a TriggerResult:

TriggerResult::continue(mixed $output = null); // proceed — $output becomes {{trigger.*}}
TriggerResult::ignore(?string $reason = null); // don't run the workflow this time

Every built-in trigger always continues with whatever payload it was given — ignore() exists for triggers (including your own) that need to apply a condition before deciding to run.

Trigger config, like node config

A trigger declares its own configuration the same way a node does — a schema() using the Schema API — and is configured the same way in a workflow definition:

'trigger' => ['type' => '@wf::trigger.schedule', 'config' => ['cron' => '*/5 * * * *']]

Applying trigger changes

Webhook, Schedule, and Model triggers wire themselves up (registering a route, a cron entry, or a model event listener) once, when your application boots — not the moment you save the workflow. After creating or editing a workflow that uses one of these, restart your application and any queue workers for the change to take effect. workflow:build prints a reminder when this applies. Manual triggers need no such restart.

Next