Triggers

  • Release version: Australia
  • Updated March 12, 2026
  • 3 minutes to read
  • Summarize
    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 Triggers

    Triggers in ServiceNow Playbooks define when a playbook should start running by specifying trigger types and conditions. You configure triggers during playbook creation in Workflow Studio to automate processes based on specific record operations or schedules within the ServiceNow AI Platform®. Triggers can be set to activate your playbook automatically or via API calls.

    Show full answer Show less

    Trigger Types

    Available trigger types include:

    • Scheduled: Runs the playbook at defined times and intervals.
    • When record is created: Fires when a user creates a new record.
    • When record is updated: Fires when a user updates an existing record.
    • When record is created or updated: Fires on both creation and update of records.

    Note that triggers only fire for interactive user-initiated record operations, not for non-interactive system operations.

    Configuration Options

    After adding a trigger, you can refine when it fires by:

    • Setting field conditions using the condition builder to control playbook activation.
    • Enabling trigger on extended tables to include tables that inherit from the selected table, broadening the trigger scope.
    • Activating trigger on unique changes to non-system fields, so the playbook runs only on distinct record updates, avoiding repeated triggers on the same change.

    Design Considerations

    • Use unique filter conditions for triggers on the same table to prevent overlapping playbook executions and unpredictable run order.
    • Avoid duplicating triggers that exist in Workflow Studio flows, as both will run independently when conditions are met.
    • Triggers ignore records added or updated via import sets or update sets, ensuring playbooks respond only to interactive changes.
    • Be cautious with triggers firing on unique changes in non-interactive sessions, as this may cause recursive playbook runs.

    Practical Use

    ServiceNow customers can create and configure triggers to automate playbooks efficiently, ensuring they run at appropriate times or in response to specific record events. Scheduled triggers support flexible timing, including time zone management and optional end dates. If default triggers do not meet your needs, you can define custom trigger definitions to better align with your business processes.

    Triggers specify when to start running your playbook.

    In Playbooks, triggers indicate when your playbook should start running. Each trigger has a type and conditions that, when met, start running your activated playbook.

    You choose one or more triggers when you create a playbook in Workflow Studio. To add a trigger, start by choosing the trigger type. Then, set conditions and other options to refine your trigger so that it fires in a way that makes sense for your business process. Repeat if you want your playbook to run based on multiple triggers. For more information, see Create a process definition.
    Note:
    You can also configure and activate a playbook without any trigger, if you're planning to only trigger the playbook via API.

    If you don't see a trigger that fits your use case, you can also create your own trigger definition instead. For more information, see Create a trigger definition.

    Figure 1. How triggers work
    When the conditions specified in your trigger are met anywhere in the ServiceNow AI Platform, your automated playbook starts running.

    Trigger types

    In your Trigger Definition [sys_pd_trigger_definition] record, you can choose a trigger type, which determines when your trigger fires. These trigger types represent record operations that can occur in the ServiceNow AI Platform®. The following trigger types are available in your instance by default:

    Scheduled
    The playbook runs on a schedule specified by the playbook author.
    When record is created
    The playbook runs when a user creates a record anywhere in the ServiceNow AI Platform.
    When record is updated
    The playbook runs when a user updates an existing record anywhere in the ServiceNow AI Platform.
    When record is created or updated
    The playbook runs when a user creates a record or updates an existing record anywhere in the ServiceNow AI Platform.
    Note:
    Triggers only fire for record operations that are interactive, or made by users. Triggers don't fire for non-interactive record operations. For more information, see Non-interactive sessions.

    Details

    After you add a trigger to your playbook, you can then set conditions and other options that determine when and how your trigger fires.

    Option Action
    Conditions Use the condition builder to create field conditions for when your playbook runs. See Condition builder.
    Run this trigger on extended tables Select this option to trigger the playbook on tables that extend from your selected table. For example, if you enable this option and select the Configuration Item [cmdb_ci] table, your playbook runs when record operations occur on the Server [cmdb_ci_server], Computer [cmdb_ci_computer], and other extended tables. For more information, see Table extension and classes.
    Trigger on unique change Select this to trigger the playbook for every unique update to a non-system field even if the flow is currently running. 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 playbook runs. However, if the State field then changes back to In Progress, the playbook doesn't run.
    Note:
    Playbooks that have a trigger that runs For each unique change can produce recursions when run in a non-interactive session. When such playbooks make a change to the trigger record, the change meets the playbook's trigger conditions and causes a recursion.

    Design considerations

    Refer to these design considerations when working with triggers:
    Create unique filter conditions for record triggers on the same table
    To prevent playbooks from overwriting each other, create unique filter conditions for each playbook that runs on the same table. If multiple playbooks on the same table have the same filter, there is no way to know the order in which the playbooks will run.
    Avoid duplicating triggers used in Workflow Studio flows
    Playbooks triggers do not override Workflow Studio triggers. For both applications, when the trigger conditions are met, the automated processes run.
    Ignore records added or updated by import and update sets
    Record triggers ignore records that were added or updated by applying an update set or importing an XML file. These operations apply to the entire application or table instead of an individual record.