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

 Release :

    - brazil

ft:locale :

    - en-US

ft:publication_title :

    - Brazil Build workflows

ft:clusterId :

    - crworkflow

bundleId :

    - crworkflow

workflow :

    - Creator


---

# Triggers

# Triggers {#ariaid-title1}

Release version: Brazil  
Updated September 10, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 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 Triggers

Triggers in ServiceNow Playbooks define the specific events or conditions that start running an activated playbook.
Each trigger has a type and associated conditions, allowing you to control exactly when your playbook executes.
You can select one or multiple triggers when creating a playbook in Workflow Studio, tailoring the trigger behavior to match your business process requirements.
Additionally, playbooks can be activated without triggers if you plan to initiate them via API calls.
Custom trigger definitions can also be created if the default options do not fit your use case.
Show full answer Show less  

## Trigger Types

ServiceNow provides several default trigger types that correspond to record operations within the ServiceNow AI Platform®:

* **Scheduled:** Runs the playbook on a defined schedule set by the playbook author.
* **When record is created:** Fires upon creation of a record.
* **When record is updated:** Fires when an existing record is updated.
* **When record is created or updated:** Fires on both creation and update of records.

Note that triggers only respond to interactive (user-initiated) record operations and do not fire for non-interactive updates such as those made by import sets or update sets.

## Configuring Trigger Details

After adding a trigger to a playbook, you can refine its behavior by setting conditions and options:

* **Conditions:** Use the condition builder to specify field-based criteria for when the playbook should run.
* **Run on extended tables:** Enable this to apply the trigger to records in tables extending from the selected table, broadening the trigger's scope.
* **Trigger on unique change:** Configure the playbook to run only for unique updates on non-system fields, preventing repeated triggers from the same field changes.

Be cautious with the *Trigger on unique change* option, as it can cause recursion if the playbook itself updates the triggering record in a non-interactive session.

## Design Considerations

* **Unique filter conditions:** When multiple playbooks have triggers on the same table, use unique filter conditions to prevent conflicts or overwriting.
* **Avoid duplicating triggers:** Playbook triggers do not replace Workflow Studio triggers; both will run if their conditions are met.
* **Ignore import/update set changes:** Triggers do not activate for records updated via import sets or update sets, as these are not individual interactive record operations.

## Practical Usage

* **Creating trigger definitions:** Define the trigger type and its conditions to control playbook activation.
* **Adding triggers in playbooks:** Start your playbook design by adding and configuring one or more triggers in Workflow Studio.
* **Scheduled triggers:** Schedule playbooks to run at specific times and intervals, with options for time zones and end dates.

Overall, triggers empower ServiceNow customers to automate playbook execution precisely when needed, enhancing process automation and ensuring workflows respond appropriately to user-driven record changes or scheduled events.  
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](https://www.servicenow.com/docs/yBpzwNedoxYMenHC5Zzx6Q "Create a playbook to set up an automated business process. Use Playbook builder in Workflow Studio to add stages, activities, triggers, and runtime permissions, then activate the playbook to make it available to agents and fulfillers.").  
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](https://www.servicenow.com/docs/_E3YSV3WovBQ4Dlhzfuvfw "Define the type of trigger that determines when to start running your playbook.").  
Figure 1. How triggers work

## Trigger types {#process-automation-designer-triggers__section_gvx_2mj_skb}

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](https://www.servicenow.com/docs/access?context=c_NonInteractiveSessions&version=brazil&pubname=brazil-platform-administration&ft:locale=en-US).

## Details {#process-automation-designer-triggers__section_zvf_kmg_ykb}

After you add a trigger to your playbook, you can then set conditions and other options that determine when and how your trigger fires.
{#process-automation-designer-triggers__table_gcm_lhz_slb__entry__2}

| Option | Action |
|-|-|
| Conditions | Use the condition builder to create field conditions for when your playbook runs. See [Condition builder](https://www.servicenow.com/docs/access?context=c_ConditionBuilder&version=brazil&pubname=brazil-platform-user-interface&ft:locale=en-US). |
| 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](https://www.servicenow.com/docs/access?context=table-extension-and-classes&version=brazil&pubname=brazil-platform-administration&ft:locale=en-US). |
| Trigger on unique change | Select this to trigger the playbook for every unique update to a non-[system field](https://www.servicenow.com/docs/access?context=r_GlobalDefaultFields&version=brazil&pubname=brazil-platform-administration&ft:locale=en-US) 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. |
[ ]

{#process-automation-designer-triggers__table_gcm_lhz_slb}

## Design considerations {#process-automation-designer-triggers__section_qpb_vjz_slb}

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.
* **[Create a trigger definition](https://www.servicenow.com/docs/_E3YSV3WovBQ4Dlhzfuvfw)**   
  Define the type of trigger that determines when to start running your playbook.
* **[Add and configure a trigger in a playbook](https://www.servicenow.com/docs/xHErHQTSYxnhiSkZWhdjKA)**   
  Begin building your playbook by adding and configuring the trigger.
* **[Create a scheduled trigger for Playbook](https://www.servicenow.com/docs/flS3BYEgfcgn3~~6vaAFjw)**   
  Create a scheduled trigger that starts your playbook at the required time and interval. You can schedule a trigger in any time zone, with or without an end date for the schedule.