Saved flow triggers
Summarize
Summary of Saved flow triggers
Saved flow triggers in the Yokohama release enable ServiceNow customers to save a set of trigger definitions as reusable triggers. This feature allows flow authors to select from predefined triggers across one or multiple application flows, improving efficiency by avoiding repetitive trigger creation. Authors can also be granted permissions to view trigger details or add conditions without altering the original saved trigger.
Show less
Key Features
- Reuse and Manage Triggers: Save triggers for reuse in multiple flows and push updates centrally to all flows using a saved trigger.
- Workflow Studio Integration: The Workflow Studio home page includes a Triggers option for managing saved triggers, with a dedicated Create trigger tab containing controls for undo/redo, view/publish states, and auto-save status.
- Trigger Configuration: Define trigger types and tables (record-based triggers only, as of Yokohama release), specify conditions, and control author permissions to view or modify conditions without affecting the saved trigger.
- Advanced Options: Configure user session requirements such as interactive vs non-interactive sessions, user-based trigger restrictions, table scope (current or extended tables), and execution context (foreground or background).
Practical Considerations
- Session Type: Choose whether the flow triggers only in interactive sessions, non-interactive sessions, or both, adapting flows to different user or system contexts.
- User Restrictions: Limit triggering to specific users or exclude certain users to control flow execution.
- Table Scope: Define whether triggers apply only to the selected table or also to tables that extend it.
- Execution Mode: Decide if the flow runs asynchronously in the background (default) for non-urgent processes or synchronously in the current session for immediate updates, noting that foreground execution may block the session and should be used cautiously.
- Modifiable Options: Flow authors can be allowed to modify advanced options when using saved triggers; such changes remain independent of future trigger updates.
Benefits
- Streamlines flow authoring by providing reusable trigger definitions.
- Centralizes trigger management, reducing maintenance effort.
- Supports flexible trigger configuration and user permissions.
- Improves flow performance and user experience by allowing control over execution context.
Next Steps
ServiceNow customers can create, edit, or delete saved triggers within Workflow Studio to leverage these capabilities effectively in their flow automation projects.
Save a set of trigger definitions as a reusable trigger. Enable flow authors to select the saved trigger from some or all application flows. Specify whether flow authors can see the trigger details or add conditions to the trigger.
Benefits
- Allow flow authors to select predefined trigger definitions without the hassle of creating a trigger.
- Push changes to every flow that uses a saved trigger rather than having to update each flow manually.
- Reuse trigger definitions in multiple flows.
UI elements
The Workflow Studio home page displays a Triggers option in the list of available components and the list of new components.
- 1. Action controls
- Redo or undo an action that you have performed while creating the trigger.
- 2. View and publish buttons
- View the draft version of the trigger for all latest changes or view the published trigger. Publish the trigger for users to see.
- 3. Auto-save icon
- View whether your changes are automatically saved.
- 4. Trigger type & table section
- Select the trigger type and table from the available options.
For more information about trigger types, see Workflow Studio flow trigger types.
- 5. Conditions section
-
Specify the conditions for the trigger. Add more conditions as you need.
You can allow flow authors to view the conditions or to view and add more conditions when they use the saved trigger in a flow. The changes don't affect the saved trigger.
- 6. Advanced Options section
-
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.
Table 1. Interactive session drop-down menu options Option Description Only Run for Non-Interactive Session Flow that is triggered only in non-interactive sessions. See Non-interactive sessions. 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 2. User drop-down menu options 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 ( ) 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 ( ) to add users to the list.
Run for any user Flow that runs for any user. Table 3. Table drop-down menu options 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. - 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 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.