Flow Designer Triggers in ServiceNow: Every Type Explained

Why the trigger matters so much

In legacy Workflow, triggers were simple — a workflow attached to a table and fired on transitions. Flow Designer is more powerful but also more nuanced. The trigger determines:

• What initiates the flow — a record change, a schedule, a platform event, or an explicit call from another flow
• What data is available — a record trigger provides the triggering record as a data pill; a scheduled trigger may not have a single record context
• How often the flow fires — an over-broad trigger on a busy table can fire thousands of times per day
• Whether the flow can run multiple times for the same record

Getting the trigger right is worth more than any amount of optimisation elsewhere in the flow.

Record-based triggers

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

Created

Fires once when a new record is inserted into the table. Use for onboarding flows, initial notifications, or setting up related records when something new is created.

Table: incident
Trigger: Created
Condition: Priority = 1 (Critical)

Use case: When a P1 incident is created, immediately notify the on-call manager and create a war room record.

Updated

Fires when a record is updated and the trigger condition evaluates to true. The most common trigger type and the one most prone to being misconfigured.

Table: incident
Trigger: Updated
Condition: State changes to Resolved

Use case: When an incident is resolved, send a satisfaction survey to the caller and update the related problem record.

Important: "Updated" fires on any field update if no condition is specified. On the incident table in a busy instance, that means thousands of executions per day. Always add a specific condition.

Created or Updated

Fires on both insert and update. Use when the same logic should run whether the record is new or has been changed. Less common — most use cases benefit from separating create and update logic.

Deleted

Fires when a record is deleted. Use for cleanup logic — removing related records, logging deletion events, or notifying stakeholders. Note: the record is already deleted when this trigger fires, but the data is available as a data pill from the trigger context.

The run trigger setting — the most misunderstood option

On record-based triggers, the Run trigger setting controls how many times the flow can execute for a given record. It is the setting developers get wrong most often.

Once

The flow runs the first time the trigger conditions are met for a record, then never again for that record — even if the conditions become true again later.

Use case: Onboarding notification — send a welcome email when a user's first incident is created.
Setting: Once
Why: You want this to fire exactly once per record, not every time the state changes.

Always

The flow runs every time the trigger conditions evaluate to true on any update. If the triggering field changes to the triggering value, then back, then to the triggering value again, the flow fires three times.

Use case: Send a notification every time a comment is added.
Setting: Always
Why: Every comment addition should trigger the notification, not just the first one.

For each unique change

The flow runs when the triggering condition changes from false to true. If it is already true and remains true, the flow does not re-fire. If it becomes false and then becomes true again, it fires again.

Use case: Escalation flow — escalate when priority changes to P1.
Setting: For each unique change
Why: Fire when state transitions TO resolved, not on every update while resolved.
This prevents re-escalating a P1 that was already P1.

The practical decision: if you want the flow to fire once ever, use Once. If you want it to fire every time the condition is true, use Always. If you want it to fire when a condition transitions from false to true, use For each unique change.

Trigger conditions — the gatekeeper

The trigger condition is evaluated before the flow starts. If it evaluates to false, the flow does not execute at all — no execution record is created, no data pills are resolved, no steps run. This is why trigger conditions are important for performance.

// Expensive — fires on every incident update
Table: incident
Trigger: Updated
No condition

// Better — fires only when the specific relevant change happens  
Table: incident
Trigger: Updated
Condition: State changes to 6 (Resolved) AND Resolved by is not empty

Build trigger conditions using the condition builder — you can use the same field conditions, operators, and dot-walking as in list view filters. See encoded query operators for reference on the condition syntax.

Schedule-based triggers

Runs on a timer rather than in response to a record change. Use for periodic processing, reports, SLA monitoring, cleanup jobs, and any automation that should run at a specific time regardless of record changes.

Daily

Trigger: Daily
Time: 07:00 UTC
Use case: Send daily digest of open P1 incidents to the service desk manager.

Weekly

Trigger: Weekly  
Day: Monday
Time: 08:00 UTC
Use case: Generate and email the weekly SLA performance report.

Monthly

Trigger: Monthly
Day: 1 (first of month)
Time: 06:00 UTC
Use case: Archive completed change records older than 90 days.

Repeat (every N minutes/hours)

Trigger: Repeat
Every: 15 minutes
Use case: Check for incidents that have breached SLA in the last 15 minutes and escalate them.

Caution with high-frequency schedules: a flow that runs every 5 minutes and queries large tables can cause significant database load. Always set appropriate query limits inside these flows and consider whether a Scheduled Script Execution might be more efficient for high-volume data processing.

Application-based triggers

These triggers fire in response to specific platform events rather than direct record changes.

Service Catalog

Fires when a catalog item request is submitted. This is the recommended way to automate catalog item fulfillment in modern ServiceNow implementations.

Trigger: Service Catalog
Catalog Item: New Employee Laptop Request

Use case: When an employee submits the laptop request catalog item, create provisioning tasks for IT, update the asset management table, and notify the requester.

Data pills available:
→ Requested Item (the RITM record)
→ Requested Item > Variables (all catalog variables as pills)
→ Requested Item > Requested For (the user who submitted)

Inbound Email

Fires when an email arrives matching specific filter conditions. Replaces legacy email business rules for most use cases.

Trigger: Inbound Email
Condition: Subject contains "URGENT"

Use case: When an email with "URGENT" in the subject arrives, create a P1 incident and assign it to the on-call team.

Data pills available:
→ Email > Subject
→ Email > Body  
→ Email > From
→ Email > Reply To

SLA

Fires when a task SLA reaches a specified breach percentage. Replaces legacy SLA workflow stages.

Trigger: SLA
Table: Incident
SLA Definition: Resolution SLA
Percentage: 75 (fires when 75% of SLA time has elapsed)

Use case: When an incident is 75% through its resolution SLA, notify the assignment group manager and add a work note.

You can add multiple SLA triggers — one at 50%, one at 75%, one at 100% — each triggering a progressively more urgent escalation. For more on SLA management, see the SLA management guide.

Metric

Fires when a Performance Analytics metric crosses a defined threshold. Use for automated responses to KPI breaches.

Trigger: Metric
Metric: Average resolution time
Threshold: Exceeds 24 hours

Use case: When average resolution time exceeds 24 hours, create a management report and schedule a review meeting.

Subflow triggers

Subflows are not triggered by external events — they are called explicitly from a parent flow or another subflow. The "trigger" of a subflow is really its input variable definition: you specify what inputs the subflow expects, and those become the parameters the calling flow must provide.

Subflow: Send Manager Escalation Notification
Trigger: (Subflow — no external trigger)
Inputs:
  - incident_record (Reference: Incident) — required
  - escalation_reason (String) — required  
  - urgency_level (Integer) — optional, default 2

Outputs:
  - notification_sent (Boolean)
  - notification_sys_id (String)

The subflow is called from a parent flow using the Run Subflow action. For the full subflow guide, see Subflows in Flow Designer.

Trigger performance — what every developer should know

Every trigger execution has a cost, even if the flow exits immediately after the trigger condition check fails. On busy tables, a poorly scoped trigger can create thousands of executions per hour — each one consuming resources even before the first step runs.

Trigger performance guidelines:

• Always use a trigger condition on record-based triggers — a trigger with no condition on the Incident table fires on every single incident save across your instance
• Use "changes to" conditions, not just "equals" — "State = Resolved" fires whenever the state is Resolved (including every subsequent save of a resolved incident); "State changes to Resolved" fires only on the transition
• For high-frequency tables, prefer For each unique change over Always — prevents repeated executions when a condition stays true across multiple saves
• Scheduled triggers with short intervals need careful scoping — a flow that runs every 5 minutes must be designed to complete quickly and not queue up executions
• Consider the table volume — a trigger on cmdb_ci that fires on any update will fire constantly during Discovery scans; scope it to specific CI classes or change types

For a broader discussion of when Flow Designer is the right tool versus other options, see Flow Designer vs Business Rules. For building maintainable flows once the trigger is configured, see Flow Designer best practices.

Trigger data pills — what each trigger type provides

Each trigger type provides a different set of data pills as starting points for the flow:

Trigger type	Available data pills
Record Created/Updated	Trigger record (all fields), Previous values (on update)
Scheduled	Execution time only — no record context unless you add a Look Up step
Service Catalog	Requested Item, catalog variables, requested for user
Inbound Email	Email subject, body, from, reply-to, attachments
SLA	Task record, SLA record, breach percentage, elapsed time
Subflow	Input variables defined in the subflow trigger

For the complete data pills reference, see Flow Designer variables and data pills.