Product documentation Docs
    • English
    • Deutsch
    • 日本語
    • 한국어
    • Français
  • More Sites
    • Now Community
    • Developer Site
    • Knowledge Base
    • Product Information
    • ServiceNow.com
    • Training
    • Customer Success Center
    • ServiceNow Support Videos
  • Log in

Product documentation

  • Home
How search works:
  • Punctuation and capital letters are ignored
  • Special characters like underscores (_) are removed
  • Known synonyms are applied
  • The most relevant topics (based on weighting and matching to search terms) are listed first in search results
Topics are ranked in search results by how closely they match your search terms
  • A match on the entire phrase you typed
  • A match on part of the phrase you typed
  • A match on ALL of the terms in the phrase you typed
  • A match on ANY of the terms in the phrase you typed

Note: Matches in titles are always highly ranked.

  • Release version
    Table of Contents
    • Now Platform capabilities
Table of Contents
Choose your release version
    Home Paris Now Platform Capabilities Now Platform capabilities Flow Designer Flows Flow trigger types

    Flow trigger types

    • Save as PDF Selected topic Topic & subtopics All topics in contents
    • Unsubscribe Log in to subscribe to topics and get notified when content changes.
    • Share this page

    Flow trigger types

    The trigger specifies the conditions that start running the flow. When the trigger conditions are met, the system starts running the flow.

    Record triggers

    Use record triggers to start a flow when a record is created or updated.

    Follow these design considerations when creating record triggers.

    Add conditions to only start record flows when needed
    Use 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 filter conditions for record triggers on the same table
    To prevent flows from overwriting each other, create unique filter conditions for each flow running on the same table. If multiple flows on the same table have the same filter, there is no way to know the order in which the flows will run.
    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.
    Trigger Description
    Created Starts a flow when a record is created in a specific table.
    Updated Starts a flow when a record is updated in a specific table. Requires selecting when to run the flow.
    • For each unique change: Triggers the flow for every unique update to a non-system field 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 will run. However, if the State field then changes back to In Progress, the flow will not 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 such flows make 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 change if the flow is not currently running. This behavior is the same as the Always option in previous releases.
    • For every update: Triggers the flow every time the record is updated, regardless of whether there has already been or there currently are any running contexts for the flow.
    Created or Updated Starts a flow when a record is either created or updated in a specific table. Requires selecting when to run the flow.
    • For each unique change: Triggers the flow for every unique update to a non-system field 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 will run. However, if the State field then changes back to In Progress, the flow will not 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 such flows make 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 change if the flow is not currently running. This behavior is the same as the Always option in previous releases.
    • For every update: Triggers the flow every time the record is updated, regardless of whether there has already been or there currently are any running contexts for the flow.
    Note: Flows including approval actions should only run the trigger once.

    Date triggers

    Use date triggers to start a flow after a specific date and time or repeatedly at scheduled intervals.
    Note: Because flows are processed asynchronously, a flow with a date 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.
    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.

    Application triggers

    Use application triggers to start a flow when application-specific conditions are met.

    Trigger Description
    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.
    Service Catalog Starts a flow from a Service Catalog item request. For more information, see Create a flow with a Service Catalog trigger.
    SLA Task Starts a flow from an SLA Definition record. For more information, see Create a flow with an SLA Task trigger.

    Inbound email triggers

    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 and the Associate Record to Email action. For greater control over email attachments, you can also use the Look up email attachments action 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.

    For more information on running multiple flows on an inbound email, see Allow multiple triggers to process an inbound email.

    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 tries again to match the email to an active inbound email trigger. If at any point the email does not match an active inbound email trigger, the system tries to match the email with an active inbound email action instead.

    Figure 1. Processing emails with inbound email triggers
    Processing emails in the Inbound Email trigger
    Note: With other types of flows, you can choose to run as a system user or the user who initiates the session. However, inbound email flows always run as the sender of the inbound email. If the system does not recognize the sender, inbound email flows will run as the Guest user. The actions of inbound email flows are limited by user ACL restrictions. To test access controls for an inbound email flow, impersonate a typical inbound email user and manually trigger the flow.

    Advanced options

    Specify the user session requirements needed to start a flow with Advanced Options.
    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.

    Table 1. Interactive session options
    Option Description
    Only Run for Non-Interactive Session Flow that is only triggered in non-interactive sessions. See Non-interactive sessions.
    Only Run for User Interactive Session Flow that is only triggered in interactive sessions.
    Run for Both Interactive and Non-Interactive Sessions Flow that is triggered in all sessions.
    Table 2. User options
    Option Description
    Do not run if triggered by the following users Flow that does not trigger for a selected list of users. Click 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. Click the Add User icon (Add User Icon) to add users to the list.
    Run for any user Flow that runs for any user.
    Table 3. Table options
    Option Description
    Run only on current table Flow that is only triggered for the selected table.
    Run on current and extended tables Flow that is triggered for the selected table and any extended tables.
    Where to run the flow

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

    Option Description
    Run flow in background (default) Flow that runs asynchronously in the background. Use this option for flows that do not 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.

    Data pills available by trigger type

    Flow designers have access to data pills from the trigger.

    Trigger 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. For more information on working with array data pills, see Complex data.
    [Table Label] Table
    The Sys ID of the table containing the trigger record.
    Run Start Time:
    The Date/Time value of when the flow started.
    Date
    Run Start Time:
    The Date/Time value of when the flow started
    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 Time:
    The Date/Time value of when the flow started
    Table Name
    The table name containing the requested catalog item.

    Tags:

    Feedback
    On this page

    Previous topic

    Next topic

    • Contact Us
    • Careers
    • Terms of Use
    • Privacy Statement
    • Sitemap
    • © ServiceNow. All rights reserved.

    Release version
    Choose your release version

      Flow trigger types

      • Save as PDF Selected topic Topic & subtopics All topics in contents
      • Unsubscribe Log in to subscribe to topics and get notified when content changes.
      • Share this page

      Flow trigger types

      The trigger specifies the conditions that start running the flow. When the trigger conditions are met, the system starts running the flow.

      Record triggers

      Use record triggers to start a flow when a record is created or updated.

      Follow these design considerations when creating record triggers.

      Add conditions to only start record flows when needed
      Use 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 filter conditions for record triggers on the same table
      To prevent flows from overwriting each other, create unique filter conditions for each flow running on the same table. If multiple flows on the same table have the same filter, there is no way to know the order in which the flows will run.
      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.
      Trigger Description
      Created Starts a flow when a record is created in a specific table.
      Updated Starts a flow when a record is updated in a specific table. Requires selecting when to run the flow.
      • For each unique change: Triggers the flow for every unique update to a non-system field 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 will run. However, if the State field then changes back to In Progress, the flow will not 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 such flows make 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 change if the flow is not currently running. This behavior is the same as the Always option in previous releases.
      • For every update: Triggers the flow every time the record is updated, regardless of whether there has already been or there currently are any running contexts for the flow.
      Created or Updated Starts a flow when a record is either created or updated in a specific table. Requires selecting when to run the flow.
      • For each unique change: Triggers the flow for every unique update to a non-system field 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 will run. However, if the State field then changes back to In Progress, the flow will not 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 such flows make 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 change if the flow is not currently running. This behavior is the same as the Always option in previous releases.
      • For every update: Triggers the flow every time the record is updated, regardless of whether there has already been or there currently are any running contexts for the flow.
      Note: Flows including approval actions should only run the trigger once.

      Date triggers

      Use date triggers to start a flow after a specific date and time or repeatedly at scheduled intervals.
      Note: Because flows are processed asynchronously, a flow with a date 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.
      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.

      Application triggers

      Use application triggers to start a flow when application-specific conditions are met.

      Trigger Description
      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.
      Service Catalog Starts a flow from a Service Catalog item request. For more information, see Create a flow with a Service Catalog trigger.
      SLA Task Starts a flow from an SLA Definition record. For more information, see Create a flow with an SLA Task trigger.

      Inbound email triggers

      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 and the Associate Record to Email action. For greater control over email attachments, you can also use the Look up email attachments action 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.

      For more information on running multiple flows on an inbound email, see Allow multiple triggers to process an inbound email.

      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 tries again to match the email to an active inbound email trigger. If at any point the email does not match an active inbound email trigger, the system tries to match the email with an active inbound email action instead.

      Figure 1. Processing emails with inbound email triggers
      Processing emails in the Inbound Email trigger
      Note: With other types of flows, you can choose to run as a system user or the user who initiates the session. However, inbound email flows always run as the sender of the inbound email. If the system does not recognize the sender, inbound email flows will run as the Guest user. The actions of inbound email flows are limited by user ACL restrictions. To test access controls for an inbound email flow, impersonate a typical inbound email user and manually trigger the flow.

      Advanced options

      Specify the user session requirements needed to start a flow with Advanced Options.
      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.

      Table 1. Interactive session options
      Option Description
      Only Run for Non-Interactive Session Flow that is only triggered in non-interactive sessions. See Non-interactive sessions.
      Only Run for User Interactive Session Flow that is only triggered in interactive sessions.
      Run for Both Interactive and Non-Interactive Sessions Flow that is triggered in all sessions.
      Table 2. User options
      Option Description
      Do not run if triggered by the following users Flow that does not trigger for a selected list of users. Click 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. Click the Add User icon (Add User Icon) to add users to the list.
      Run for any user Flow that runs for any user.
      Table 3. Table options
      Option Description
      Run only on current table Flow that is only triggered for the selected table.
      Run on current and extended tables Flow that is triggered for the selected table and any extended tables.
      Where to run the flow

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

      Option Description
      Run flow in background (default) Flow that runs asynchronously in the background. Use this option for flows that do not 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.

      Data pills available by trigger type

      Flow designers have access to data pills from the trigger.

      Trigger 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. For more information on working with array data pills, see Complex data.
      [Table Label] Table
      The Sys ID of the table containing the trigger record.
      Run Start Time:
      The Date/Time value of when the flow started.
      Date
      Run Start Time:
      The Date/Time value of when the flow started
      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 Time:
      The Date/Time value of when the flow started
      Table Name
      The table name containing the requested catalog item.

      Tags:

      Feedback

          Share this page

          Got it! Feel free to add a comment
          To share your product suggestions, visit the Idea Portal.
          Please let us know how to improve this content

          Check any that apply

          To share your product suggestions, visit the Idea Portal.
          Confirm

          We were unable to find "Coaching" in Jakarta. Would you like to search instead?

          No Yes
          • Contact Us
          • Careers
          • Terms of Use
          • Privacy Statement
          • Sitemap
          • © ServiceNow. All rights reserved.

          Subscribe Subscribed Unsubscribe Last updated: Tags: January February March April May June July August September October November December No Results Found Versions Search preferences successfully updated My release version successfully updated My release version successfully deleted An error has occurred. Please try again later. You have been unsubscribed from all topics. You are now subscribed to and will receive notifications if any changes are made to this page. You have been unsubscribed from this content Thank you for your feedback. Form temporarily unavailable. Please try again or contact  docfeedback@servicenow.com  to submit your comments. The topic you requested does not exist in the release. You were redirected to a related topic instead. The available release versions for this topic are listed There is no specific version for this documentation. Explore products Click to go to the page. Release notes and upgrades Click to open the dropdown menu. Delete Remove No selected version Reset This field is required You are already subscribed to this topic Attach screenshot The file you uploaded exceeds the allowed file size of 20MB. Please try again with a smaller file. Please complete the reCAPTCHA step to attach a screenshot
          Log in to personalize your search results and subscribe to topics
          No, thanks Login