Triggers
A trigger is what makes a workflow run. There are four types, and the choice is mostly about who starts the run: a person, the clock, an external system, or the platform itself.
| Type | Started by | Run payload | Detail |
|---|---|---|---|
manual | A person, from the editor | Whatever you supply when you start the run | This page |
schedule | A cron expression in a timezone | The firing context | Schedule triggers |
webhook | An HTTP call from outside | The request's body, query, headers and method | Webhook triggers |
event | A platform event matching a subject pattern | The event envelope | Event triggers |
What is true of all four
Triggers are separate records, not nodes. They are not part of the workflow document, a workflow can carry several of them, and they only ever appear on the from side of an edge — a trigger has no input.
Each trigger has its own handle. A trigger is identified by a UUID of its own, which is what the canvas wires an edge from and what a webhook address is issued against. Two triggers of the same type on one workflow are two separate records with two separate handles; nothing is shared between them.
A trigger can be active or inactive. An inactive trigger is skipped at dispatch time, and a run needs at least one active trigger plus an active workflow. Deactivating a trigger is how you stop one path into a workflow without pausing the whole thing.
A firing is not a run. A trigger firing while the workflow's build is not ready does not produce a run; the firing lands under Missed runs where you can replay or discard it.
Whatever the trigger produces is readable from any node as ${{ trigger.payload.… }} — see Expressions.
Manual
A manual trigger is the start button. You run the workflow from the editor, on demand.
A workflow may have at most one manual trigger. Adding a second is rejected.
There is nothing to configure on it. The payload comes from the run itself: if any node in the workflow reads from trigger.payload, starting the run asks you for a payload first, and what you supply is what those expressions resolve against. A payload that is not valid JSON stops the run and says so.
Reach for it while you are building — a manual run is the fastest honest test of a whole workflow — and keep it after you go live, as the way to re-run a job by hand without waiting for the next scheduled firing. A workflow can carry both a manual trigger and a schedule feeding the same chain; that is what the BMECAT template does.
A manual run is a real run. It appears in the run history, it writes what the workflow tells it to write, and it consumes the same credentials. Test against a system you are allowed to write to.
What there isn't
There is no polling trigger. If a workflow needs to notice a change in a system that neither calls you nor emits platform events, put it on a schedule and have the first node ask — an SFTP directory listing, or an HTTP call filtered by a timestamp you keep. That is the shape the file-based templates use.
Where to go next
- Schedule triggers — the clock.
- Webhook triggers — an external system.
- Event triggers — the platform itself.
- Execution modes — the build gate every trigger passes through, and who waits for the result.
- Expressions — reading
trigger.payloadand everything else.