Triggers
Summarize
Summary of Triggers
Triggers in ServiceNow Playbooks define when a playbook should start running based on specific events or conditions. They enable automation by specifying trigger types and conditions that initiate playbook execution. Triggers can be added and configured within Workflow Studio, allowing you to tailor when and how your playbook runs according to your business processes. Multiple triggers can be used per playbook, or a playbook can run without triggers if it is activated via API.
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.
- When record is created: Fires when a user creates a record.
- When record is updated: Fires when a user updates a record.
- When record is created or updated: Fires on either creation or update of a record.
Note that triggers only fire for interactive user actions, not for non-interactive sessions such as automated imports or update sets.
Trigger Configuration Options
After adding a trigger, you can refine its behavior by setting:
- Conditions: Use the condition builder to specify field-based criteria that must be met for the playbook to run.
- Run on extended tables: Optionally enable triggering on tables that inherit from the selected table, broadening the trigger's scope.
- Trigger on unique change: Fires the playbook only for unique updates to non-system fields, preventing multiple runs on repeated changes to the same value. Use caution as this can cause recursion in non-interactive sessions.
Design Considerations
- Create unique filter conditions on the same table to avoid playbooks overwriting each other or running unpredictably.
- Avoid duplicating triggers between Playbooks and Workflow Studio flows, as both will run independently when conditions are met.
- Triggers ignore records created or updated via import sets or update sets to prevent unintended executions.
Practical Guidance
To implement triggers effectively:
- Define a trigger type that aligns with your business event.
- Add and configure the trigger within your playbook in Workflow Studio.
- Use scheduled triggers to automate playbooks at specific times or intervals, configurable by time zone and with optional end dates.
- If needed, create custom trigger definitions when default types don’t meet your needs.
This setup helps ensure that your playbooks run precisely when needed, improving automation reliability and aligning with your operational workflows.
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.
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.
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.
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
- 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.