---
sourceDocument: Yokohama Build workflows
sourceDocumentLink: https://www.servicenow.com/docs/r/yokohama/build-workflows

 Release :

    - yokohama

ft:locale :

    - en-US

ft:publication_title :

    - Yokohama Build workflows

ft:clusterId :

    - crworkflow

bundleId :

    - crworkflow

workflow :

    - Creator


---

# Flow trigger types

# Workflow Studio flow trigger types {#ariaid-title1}

* Release version: Yokohama
* 
* Updated July 31, 2025
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 13 minutes to read

Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI  
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.  

## Summary of Workflow Studio flow trigger types

Workflow Studio flow triggers define when a flow starts and the data available at start.
Triggers cover record operations, scheduled times, REST API requests, application-specific events, inbound emails, and external spokes.
Understanding trigger types helps you design flows that start precisely when needed, optimizing system resources and flow effectiveness.
Show full answer Show less  

## Record Triggers

Record triggers initiate flows based on record creation or updates in non-system tables. Key options include:

* **Created:** Starts a flow when a record is created.
* **Updated:** Starts a flow on record update with options like triggering on each unique change, once per record, or every update regardless of flow state.
* **Created or Updated:** Combines creation and update triggers with similar run conditions as updated triggers.

Note that some common records have dedicated application triggers. Use "For each unique change" with caution to avoid recursion, especially in non-interactive sessions. Flows with approvals should trigger only once per record to avoid duplicate approvals.

## REST Triggers

REST API asynchronous triggers start flows from inbound API calls or webhooks without custom code. This requires an Integration Hub Enterprise subscription.

## Scheduled Triggers

Scheduled triggers start flows at specific times or intervals using instance timezone:

* Daily, Weekly, Monthly: Trigger flows at set times on those schedules.
* Run Once: Triggers one time at a specified date/time or as soon as possible if scheduled in the past.
* Repeat: Triggers at defined regular intervals.

Flows run asynchronously so exact trigger time may vary depending on system load.

## Application Triggers

These triggers start flows based on application-specific events:

* **Kafka Message:** Starts on new Kafka topic messages.
* **MetricBase:** Starts when MetricBase triggers occur (requires MetricBase app).
* **Proactive Analytics:** Starts on KPI or threshold events (requires Performance Analytics subscription).
* **Service Catalog:** Starts from catalog item requests (variables handled inside flow).
* **SLA Task:** Starts from SLA Definition records.

## Inbound Email Triggers

Flows start when emails arrive. Inbound email triggers have priority over email actions and provide enhanced control over attachments and record association. Emails are processed sequentially by triggers and, if needed, email actions. Flows run using the sender's user context or Guest user if unknown, ensuring access controls apply. Multiple inbound email flows require special configuration.

## Spoke Triggers

Spoke triggers respond to external third-party events or webhooks, such as issue creation in external systems, which update ServiceNow records and start flows.

## Advanced Options

Configure when and how flows run:

* **Session Type:** Choose to run flows in interactive sessions, non-interactive sessions, or both.
* **User Restrictions:** Define which users can or cannot trigger the flow.
* **Table Scope:** Limit triggers to current or extended tables.
* **Execution Context:** Run flows asynchronously in background (default) or synchronously in foreground for immediate updates.

## Data Pills by Trigger Type

Flows receive data pills specific to their trigger type, enabling use of trigger record data, changed fields, timestamps, REST request details, SLA records, email content, Kafka messages, and more. This data supports rich flow logic and actions.

## Best Practices

* Use triggers for fixed start conditions; use subflows for variable input.
* Add precise conditions to record triggers to optimize performance and avoid unnecessary runs.
* Create unique trigger conditions per table to prevent flow conflicts.
* Ignore records changed by import or update sets to avoid unintended triggers.
* Replace Service Catalog record triggers with application triggers.
* Ensure users triggering flows have access to all data in trigger conditions; run flows with elevated roles when needed to access restricted data.  
Each trigger type defines when a flow starts and the starting data available to it. There are triggers for record operations, dates, and application operations.

## Record triggers {#flow-triggers__section_g4f_h1q_jdb}

Use record triggers to start a flow when a record is created or updated.  
{#flow-triggers__table_rvf_njy_mbb__entry__2}

| Trigger | Description |
|-|-|
| Created | Starts a flow when a record is created in a specific non-system table. Note: Some common record types such as requests have their own dedicated triggers. See the application trigger types for a list of application records that have dedicated triggers. |
| Updated | Starts a flow when a record is updated in a specific non-system table. Requires selecting when to run the flow. * For each unique change: Triggers the flow for every unique update to a non-[system field](https://www.servicenow.com/docs/access?context=r_GlobalDefaultFields&version=yokohama&pubname=yokohama-platform-administration&ft:locale=en-US) even if the flow is currently running. Note: The system stores a history of every change to a record and determines whether the change is unique. For example, if an incident record's State field changes from In Progress to On Hold, the flow can run. However, if the State field then changes back to In Progress, the flow can't run. Note: Flows that have a record trigger that runs For each unique change can produce recursions when run in a non-interactive session. When this type of flow makes a change to the trigger record, the change meets the flow trigger conditions and causes a recursion. * Once: Triggers the flow once for the life of the record. * Only if not currently running: Triggers the flow for every unique record change if the flow is not currently running on this record. This behavior is the same as the Always option in previous releases. * For every update: Triggers the flow every time that the record is updated, regardless of whether there has already been or currently are any running contexts for the flow. {#flow-triggers__ul_ys1_ggn_yfb} |
| Created or Updated | Starts a flow when a record is either created or updated in a specific non-system table. Requires selecting when to run the flow. * For each unique change: Triggers the flow for every unique update to a non-[system field](https://www.servicenow.com/docs/access?context=r_GlobalDefaultFields&version=yokohama&pubname=yokohama-platform-administration&ft:locale=en-US) even if the flow is currently running. Note: The system stores a history of every change to a record and determines whether the change is unique. For example, if an incident record's State field changes from In Progress to On Hold, the flow can run. However, if the State field then changes back to In Progress, the flow can't run. Note: Flows that have a record trigger that runs For each unique change can produce recursions when run in a non-interactive session. When this type of flow makes a change to the trigger record, the change meets the flow trigger conditions and causes a recursion. * Once: Triggers the flow once for the life of the record. * Only if not currently running: Triggers the flow for every unique record change if the flow is not currently running on this record. This behavior is the same as the Always option in previous releases. * For every update: Triggers the flow every time that the record is updated, regardless of whether there has already been or currently are any running contexts for the flow. {#flow-triggers__ul_hpm_ggn_yfb} |
[ ]

{#flow-triggers__table_rvf_njy_mbb}  
Note:  
Flows including approval actions should only run the trigger once. In cases where you need to update and resubmit an approval, consider using a [Go back to flow logic](https://www.servicenow.com/docs/bhUS9xEo2lNvyY9~JY5mqA "Return to a prior step in the flow to repeat a sequence of actions.") to ask for approval again.

## REST triggers {#flow-triggers__section_nkv_vmz_jnb}

Use REST triggers to start a flow after a specific REST API request.  
Note:  
This feature requires an Integration Hub Enterprise subscription. For more information, see [Request Integration Hub](https://www.servicenow.com/docs/access?context=request-ih-overview&version=yokohama&pubname=yokohama-integrate-applications&ft:locale=en-US).  
{#flow-triggers__table_eyn_bnz_jnb__entry__2}

| Trigger | Description |
|-|-|
| REST API - Asynchronous | Start a flow from an inbound API call or webhook from an external system. Configure the trigger start conditions without having to write or maintain custom code. For more information, see REST API trigger. |
[ ]

{#flow-triggers__table_eyn_bnz_jnb}

## Scheduled triggers {#flow-triggers__section_fzl_h1q_jdb}

Use scheduled triggers to start a flow after a specific date and time or repeatedly at scheduled intervals. Scheduled triggers use the instance timezone to determine when to start a flow.  
Note:  
Because flows are processed asynchronously, a flow with a scheduled trigger may not run at the exact scheduled time its trigger conditions were met. For example, if a scheduled flow is triggered during core business hours, the system may have to process other events in the queue before it can run the scheduled flow.  
{#flow-triggers__table_tkk_5jy_mbb__entry__2}

| Trigger | Description |
|-|-|
| Daily | Starts a flow at a specific time every day. |
| Weekly | Starts a flow at a specific time every week. |
| Monthly | Starts a flow at a specific time every month. |
| Run Once | Starts a flow once at a specific time but does not repeat. If you select a past date or time, the system schedules the flow to run as soon as possible. |
| Repeat | Starts a flow at regular intervals you define. |
[ ]

{#flow-triggers__table_tkk_5jy_mbb}

## Application triggers {#flow-triggers__section_hqr_h1q_jdb}

Use application triggers to start a flow when application-specific conditions are met.  
{#flow-triggers__table_gfx_xvl_ycb__entry__2}

| Trigger | Description |
|-|-|
| Kafka Message | Starts a flow when there's a message in a topic in your Kafka environment. For more information, see [Create a flow with a Kafka Message trigger](https://www.servicenow.com/docs/9Mxv9Wu~lWSKf3iwMDYRVA "Build a flow that processes events from a Kafka stream. Start the flow when an event is available in the specified topic."). |
| MetricBase | Starts a flow when a MetricBase trigger is met. Requires the MetricBase application. For more information, see [Create a flow with a MetricBase trigger](https://www.servicenow.com/docs/jG2JENgfAgiaPXypPpgJzA "Start a flow when a MetricBase trigger is met. MetricBase triggers track time series data and can monitor when a threshold is reached, when a trend is detected, or when a system stops reporting data."). |
| Proactive Analytics | Starts a flow when Proactive Analytics KPI score or KPI threshold values are met. Requires a Performance Analytics subscription to Proactive Analytics. For more information, see [Create a flow with a Proactive Analytics trigger](https://www.servicenow.com/docs/mtFCJ38Yc7_IcxNuAi0JBw "Use Performance Analytics indicators to start a flow. Define the flow start conditions as a set of Proactive Analytics KPI scores and KPI threshold values."). |
| Service Catalog | Starts a flow from a Service Catalog item request. For more information, see [Create a flow with a Service Catalog trigger](https://www.servicenow.com/docs/2tQx9zOfyTQpAtorSW~d8A "Start a flow when a Service Catalog item is requested to automate the fulfillment process."). Note: Service Catalog triggers do not support catalog variables as part of the trigger condition. Instead, get or create catalog variables in the main body of the flow. |
| SLA Task | Starts a flow from an SLA Definition record. For more information, see [Create a flow with an SLA Task trigger](https://www.servicenow.com/docs/o_Pii3X4yUcZRa2eEOx4eg "Configure your Service Level Agreement (SLA) definition to run a flow as the action plan."). |
[ ]

{#flow-triggers__table_gfx_xvl_ycb}

## Inbound email triggers {#flow-triggers__section_u4l_hfm_fhb}

Start a flow when your instance receives an email.

Inbound email flows take priority over inbound email actions. If you create flows with inbound email triggers, emails are first processed by the inbound email triggers before they are processed by inbound email actions.

With inbound email actions, you don't have full control over email attachment handling or
assigning the target record of an email. When you create a flow with an inbound email
trigger, you can perform these actions with the [Move Email Attachments to Record action](https://www.servicenow.com/docs/F7HL6mofDSEAgW8IezgGxg "Move attachments from an email to a record so that the files are available to your users when they view the record.") and the [Associate Record to Email action](https://www.servicenow.com/docs/m7PRaCWMiDYzbGHEMkcWrQ "Associate a record with an Email [sys_email] record so that you can track which record is affected by the email."). For greater control over email attachments, you
can also use the [Look up email attachments action](https://www.servicenow.com/docs/yS~xz~L39vQgIeF3obmZcw "Look up files that are attached to an email so that you can perform an action on the files.") to access a specific attachment
as a data pill.

Although you can process an inbound email with multiple inbound email actions, you can't
process an inbound email with multiple flows by default. Additional configuration is
required. For information on how to stop processing in inbound email actions, see [Specifying the inbound email processing order](https://www.servicenow.com/docs/access?context=r_OrderedEmailProcessingPlugin&version=yokohama&pubname=yokohama-platform-administration&ft:locale=en-US).

For more information on running multiple flows on an inbound email, see [Allow multiple triggers to process an inbound email](https://www.servicenow.com/docs/dyt9zMJ8RdMOgqhS5e7hOw "Configure Workflow Studio to allow an inbound email to be processed by multiple inbound email triggers in a specific order.").

The following diagram shows how inbound emails are processed by inbound email triggers. After the email has been classified as a reply, forward, or new email, the system tries to match the email to an active inbound email
trigger. If the email meets the conditions of an inbound email trigger, the flow runs. If the flow issues stop processing, the email is finished being processed. If the flow does not issue stop processing, the system evaluates
the conditions of more inbound email triggers. If there are no more inbound email triggers to evaluate, the system tries to match the email with an active inbound email action instead.  
Figure 1. Processing emails with inbound email triggers  
Important:  
Inbound email flows use the email sender as the user who initiates the session. If the system doesn't recognize the sender, the inbound email flow runs as the Guest user. Setting the inbound email flow to run as the user who initiates the session ensures that the flow actions are limited by user access controls. If the initiating user needs elevated privileges for some reason, have the inbound email flow call a subflow that runs with the required roles. To test access controls for an inbound email flow, impersonate a typical inbound email user and manually trigger the flow.

## Spoke triggers {#flow-triggers__section_g3j_q3b_sxb}

Spokes can have conditional and event-driven external triggers or webhooks that start from third-party applications. The webhooks act as the triggers that provide the data to a flow. For example, when you create a P1-level issue in a third-party issue-tracking application, it updates the incident database record in the ServiceNow instance. To implement this flow, follow these steps:

1. 
2. .
{#flow-triggers__ol_t1y_rj3_5xb}

## Advanced options {#flow-triggers__section_ztn_nlc_mfb}

Specify the user session requirements needed to start a flow in the Advanced Options section.

When to run the flow

:   Determine the type of session that can trigger the flow, whether to run the flow when triggered by certain users, and which tables can trigger the flow.

    {#flow-triggers__table_crj_cmc_mfb__entry__2}

    | Option | Description |
    |-|-|
    | Only Run for Non-Interactive Session | Flow that is triggered only in non-interactive sessions. See [Non-interactive sessions](https://www.servicenow.com/docs/access?context=c_NonInteractiveSessions&version=yokohama&pubname=yokohama-platform-administration&ft:locale=en-US). |
    | Only Run for User Interactive Session | Flow that is triggered only in interactive sessions. |
    | Run for Both Interactive and Non-Interactive Sessions | Flow that is triggered in all sessions. |
    [Table 1. Interactive session drop-down menu options]

    {#flow-triggers__table_crj_cmc_mfb}  
    {#flow-triggers__table_zxz_mmc_mfb__entry__2}

    | Option | Description |
    |-|-|
    | Do not run if triggered by the following users | Flow that doesn't trigger for a selected list of users. Select the Add User icon (![Add User Icon]()) to add users to the list. |
    | Only run if triggered by the following users | Flow that triggers only for a selected list of users. Select the Add User icon (![Add User Icon]()) to add users to the list. |
    | Run for any user | Flow that runs for any user. |
    [Table 2. User drop-down menu options]

    {#flow-triggers__table_zxz_mmc_mfb}  
    {#flow-triggers__table_afh_xyk_qkb__entry__2}

    | Option | Description |
    |-|-|
    | Run only on current table | Flow that is triggered only for the selected table. |
    | Run on current and extended tables | Flow that is triggered for the selected table and any extended tables. |
    [Table 3. Table drop-down menu options]

    {#flow-triggers__table_afh_xyk_qkb}

Where to run the flow

:   Determine whether to run the flow in the background or in the current session.

    {#flow-triggers__table_qhf_fh1_phb__entry__2}

    | Option | Description |
    |-|-|
    | Run flow in background (default) | Flow that runs asynchronously in the background. Use this option for flows that don't require immediate updates and to allow other system processes to run at the same time. |
    | Run flow in foreground | Flow that runs synchronously in the current session. Use this option to provide immediate updates to an end user. For example, if a flow opens a task after the previous task closes, use this option to open the next task immediately after a user closes one. Note: Running a flow in foreground may block the current session thread and prevent user input until the flow finishes. Avoid running flows in the foreground when they contain actions that cannot be interrupted, such as actions that run script. Actions or flow logic that pause a flow will not block a session. |
    [ ]

    {#flow-triggers__table_qhf_fh1_phb}

## Data pills available by trigger type {#flow-triggers__section_plc_wqb_2jb}

Flow designers have access to data pills from the trigger.  
{#flow-triggers__table_n55_2rb_2jb__entry__2}

| Trigger Type | Data pills available |
|-|-|
| Record | \[Table Label\] Record :   An object containing the triggering record. Changed Fields :   An array of objects containing the field values that changed. This data pill is only available for the Updated or Created or Updated trigger types. Note: To process the Changed Fields array data pill, you will need to use [For Each flow logic](https://www.servicenow.com/docs/sXDICSCto7~hbNZyHxR6lQ "Apply one or more actions to each record in a list of records."). For more information on working with array data pills, see [Complex data](https://www.servicenow.com/docs/stNvDlsVTVfaHzkIx~~Etg "Use a graphical interface to work with collections of complex structured data. Help design users understand the organization of structured data, and add, remove, or configure its individual elements."). \[Table Label\] Table :   The Sys ID of the table containing the trigger record. Run Start Date/Time :   Date/Time object that stores when the flow started in the system's local timezone. Use this data pill to pass a Date/Time value to other actions and steps such as the Create record action or the Update record action. Run Start Time UTC :   Date/Time string that stores when the flow started in Coordinated Universal Time (UTC). Use this data pill to pass data to legacy flows that expect UTC date-time strings. |
| REST API - Asynchronous | Path Parameters :   An object containing path parameters in the inbound request. Query Parameters :   An object containing query parameters in the inbound request. Request Headers :   An object containing headers in the inbound request. Request Body :   Complex data object that defines the body structure of the inbound request. For more information on complex objects, see [Complex data](https://www.servicenow.com/docs/stNvDlsVTVfaHzkIx~~Etg "Use a graphical interface to work with collections of complex structured data. Help design users understand the organization of structured data, and add, remove, or configure its individual elements."). |
| Date | Run Start Date/Time :   Date/Time object that stores when the flow started in the system's local timezone. Use this data pill to pass a Date/Time value to other actions and steps such as the Create record action or the Update record action. Run Start Time UTC :   Date/Time string that stores when the flow started in Coordinated Universal Time (UTC). Use this data pill to pass data to legacy flows that expect UTC date-time strings. |
| SLA Task | Task SLA Record :   An object containing the triggering Task SLA record. sla_flow_inputs :   An Object containing Task SLA Definition values. |
| Inbound Email | Email Record :   An object containing the triggering Email record. \[Table Label\] Table :   The Sys ID of the table associated with the target email. Body Text :   A String containing the body of the email message. Subject :   A String containing the subject of the email message. User Record :   An object containing the user who sent the triggering email. If the sender does not have an associated User record, the data pill lists the object for the Guest user. From address :   A String containing the sender email address. |
| Metric Base | MetricBase Trigger Definition Record :   An object containing the triggering MetricBase Trigger Definition Record. Level :   The Integer value of the MetricBase trigger level. Time of Metric Event :   The Date/Time value of when the metric event occurred. Record :   An object containing the record for which metric events have been collected. |
| Service Catalog | Requested Item Record :   An object containing the triggering Requested Item record. Run Start Date/Time :   Date/Time object that stores when the flow started in the system's local timezone. Use this data pill to pass a Date/Time value to other actions and steps such as the Create record action or the Update record action. Run Start Time UTC :   Date/Time string that stores when the flow started in Coordinated Universal Time (UTC). Use this data pill to pass data to legacy flows that expect UTC date-time strings. Table Name :   The table name containing the requested catalog item. |
| Kafka Message | Messages :   An array of objects containing the messages received from the Kafka topic. Each message has the following data pills. * Headers: An array of headers, with each header containing a Key and a Value. The Key-Value pair provides additional information about the message. Both the Key and the Value are strings. * Payload: A string containing the text of the message. * Key: A sting identifying the insertion order for the message. Messages with the same key are processed in order. {#flow-triggers__ul_rzm_tqd_gvb} |
[ ]

{#flow-triggers__table_n55_2rb_2jb}

## General guidelines {#flow-triggers__id_ic5_rrb_ptb}

Follow these general guidelines when creating record triggers.

Determine whether your flow needs a trigger or variable input
:   Flows always run when their trigger conditions are met. Triggers always provide the same data as input for flows.
    If
    you need variable input to initiate a flow instead, create a [subflow](https://www.servicenow.com/docs/tX0aFIZsckv5T0THcwRybg#flow-triggers__subflows-design-considerations).

Add conditions to specify what record values start your flow
:   Starting a flow only when needed consumes fewer system resources than starting a flow, pausing it, and waiting to resume the flow until a specific record condition applies. Instead of creating a flow that starts with a
    Wait for condition action, redesign the flow to include the wait condition as part of the record trigger.

Create unique conditions for record triggers on the same table
:   To prevent flows from overwriting each other, create unique conditions for each flow running on the same table. If multiple flows on the same table have the same filter conditions, there is no way to know the order in
    which the flows run. Using conditions also helps to optimize flow performance by returning a more precise, smaller set of records.

Ignore records added or updated by import and update sets
:   Record triggers ignore records added or updated by applying an update set or importing an XML file. These operations apply to the entire application or table rather than an individual record.

Replace record triggers on Service Catalog tables with Service Catalog application triggers
:   Flow Designer no longer displays Service Catalog tables as options for record triggers. Instead, create flows that use the Service Catalog application trigger type.

Verify that the users who trigger a flow have access to trigger condition data
:   Since flows typically run as the user who triggers them, verify that users have access to all of the data specified in the trigger conditions. Avoid creating trigger conditions to related tables that typical users don't
    have access to. If your flow trigger conditions require access to role-restricted data, run your flows with the role needed to access that data.
{#flow-triggers__ul_rnz_svm_xsb}