Flow Designer Triggers: Every Type Explained with Real Examples

Record-based triggers

The most common trigger type. Fires when a record on a specific table is created, updated, or both.

Configuration options:

Created — fires once when the record is first inserted
Updated — fires when specified fields change
Created or Updated — fires on both operations
Deleted — fires when the record is deleted

Example: Send a Slack message when an incident is assigned:

Table: Incident
Trigger: Updated
Condition: Assigned To changes AND Assigned To is not empty

Run trigger — Once vs Always vs For each unique change

This is the most misunderstood setting on record triggers:

Once — runs the first time conditions are met, then never again for that record. Useful for onboarding flows.
Always — runs every time the conditions are met on any update
For each unique change — runs only when the triggering condition changes to true from false

Schedule-based triggers

Runs on a timer — daily, weekly, every N hours/minutes.

Trigger: Daily
Time: 08:00 UTC
Condition: (none, or filter records to process)

Use for: end-of-day reports, SLA breach checks, cleanup jobs, recurring notifications.

Application-based triggers

Triggers that fire based on platform events rather than record changes:

Inbound Email — fires when an email arrives matching filters
Service Catalog — fires when a catalog item is requested
SLA — fires when an SLA reaches a breach percentage
Metric — fires when a metric threshold is crossed

Subflow triggers

Subflows are triggered explicitly when called from a parent flow or another subflow — they do not have their own schedule or record trigger. They receive input variables defined in their trigger configuration.

Conditions vs Trigger filter

The trigger filter runs before the flow executes to decide whether it should run at all. Keep trigger filters as specific as possible — every execution has a cost even if the flow exits early.