Triggers define when automation runs. In production, most automation incidents are trigger problems, not action-node problems. Sending a message is easy. Sending exactly one message for the right event, even when providers retry and servers restart, is the hard part.
Fluxo treats triggers as reliability-critical adapters with explicit state, deduplication, and normalized payloads. The goal is that the runtime always receives a consistent event shape, and the system can explain why a run fired.
Webhook trigger
Webhook dispatch captures request metadata and emits execution with normalized payload:
- method
- headers
- content type
- signature metadata
- webhook id and trigger timestamp
This gives downstream nodes a consistent trigger contract regardless of caller variability.
Schedule trigger
Schedules are deceptively tricky because time zones and jitter are real. Fluxo parses schedule configs and evaluates due windows with timezone-aware checks. Dispatch uses deterministic event ids per workflow and run time so retries and jitter do not create duplicate runs.
Email trigger
Email trigger supports Gmail and IMAP with typed credential expectations. Fluxo persists trigger state (last UID/date) and polling filters so runs fire only for new matching messages. Without persisted state, email triggers either miss events or reprocess the same messages repeatedly.
RSS trigger
RSS polling persists lastItemGuid per workflow and node. Fluxo primes state on first run, then dispatches only unseen items in order, capped by a configured max. This keeps RSS workflows predictable even when feeds reorder or backfill.
File watcher trigger
File watcher supports Google Drive and Dropbox and tracks previous file snapshots in FileWatcherState. I compute created/modified/deleted diffs and support optional file-content base64 enrichment with a size cap.
This trigger has the most reliability logic:
- poll interval skipping
- folder path dedupe
- MIME/type/pattern/size filtering
- priming mode to avoid first-run flood
- event fingerprinting for dedupe-friendly ids
Trigger constraints I enforce
- exactly one trigger node per workflow
- trigger type-specific schema parsing
- credential type alignment per provider
- active-workflow filtering in pollers
Why this matters
Most automation incidents come from trigger ambiguity: did it run twice, why did it not fire, why did it process old items. By making trigger state explicit and persisted, Fluxo’s when-to-run behavior becomes predictable and debuggable.