Start the workflow
Start the workflow
Triggers
The four types, what they have in common, and the manual trigger.
Schedule triggers
Five-field cron in an IANA timezone, first-run semantics, and running twice.
Webhook triggers
An address issued per trigger, method matching, and what the request becomes.
Event triggers
Subject patterns, the event envelope in the payload, and dedupe on the event id.
Execution modes
The build gate, the execution_mode policy and its per-request override, and the 30-second synchronous cap.
A workflow does nothing until something starts it. Two decisions sit behind that: who starts the run — a person, the clock, an external system, or the platform itself — and whether that caller waits for the result.
The pages
- Triggers — the four types side by side, what is true of all of them, and the manual trigger in full.
- Schedule triggers — the cron expression, why the timezone is not cosmetic, when the first run happens, and designing for at-least-once.
- Webhook triggers — where the address comes from, the one method it accepts, and the four parts of the payload.
- Event triggers — subject patterns with
*and>, the envelope the workflow reads, and de-duplication on the event id. - Execution modes — what has to be true before any of them can produce a run, and who decides whether the caller waits.
The short version
| If the run is started by | Use | And read |
|---|---|---|
| A person, on demand | A manual trigger | Triggers |
| The clock | A schedule trigger | Schedule triggers |
| A system you do not control | A webhook trigger | Webhook triggers |
| Something happening in Revenue Cloud | An event trigger | Event triggers |
A workflow can carry several triggers at once, and usually should: a schedule for the unattended path, plus a manual trigger so you can re-run the job by hand without waiting for the next firing.