Exploring flows
Summarize
Summary of Exploring Flows
Flows in ServiceNow automate multi-step processes triggered under specific conditions. They consist of a trigger, a series of reusable actions, and flow logic that collectively execute defined operations. An example includes the VTB Sample Flow, which creates and assigns VTB cards upon the creation of a priority 1 incident.
Show less
Key Features
- Trigger: Defines when the flow runs, supporting various types such as record operations, Service Catalog requests, and scheduled triggers.
- Flow Execution Details: Allows authors to monitor the state of actions and outputs during runtime.
- Flow Error Handler: Catches and reports errors, enabling corrective actions or notifications to be executed.
- Subflows: Automated processes that do not have triggers and are called within flows or scripts.
- Actions: Reusable operations that automate ServiceNow features without coding, such as the Create Record action.
- Spokes: Scoped applications containing specific actions and subflows, such as the ITSM Spoke for Incident management.
- Flow Structure: Comprises four main sections: Trigger, Action, Error Handler, and Data Panel for variable management.
Key Outcomes
Utilizing flows leads to greater efficiency by automating repetitive tasks, simplifies workflow understanding with natural language descriptions, and provides a visual representation of workflows. This promotes collaboration between process owners and developers, reduces costs associated with upgrades and development, and enhances scalability with integration and RPA subscriptions.
Flows automate a repeatable multi-step process. When the flow trigger conditions are met, the flow runs a sequence of reusable actions and flow logic to complete the process.
Flows overview
A flow is an automated process consisting of a trigger, a sequence of reusable actions, and flow logic. The trigger specifies when to run the flow. The actions perform a sequence of operations on your data. For example, the VTB Sample Flow creates and assigns a VTB card whenever a priority 1 incident is created.
Flows consist of the following components.
- Trigger
- A trigger specifies when to run the flow. When the trigger conditions are met, the system runs the flow using the data provided by the trigger. Workflow Studio supports a variety of trigger types such as record, Service Catalog requests, and scheduled triggers. For a description of available trigger types, see
- Flow execution details
- A flow execution details page allows a flow author to view run-time information about an action or flow directly from the design environment. You can view details such as the current state, actions or steps run, output values generated, and errors produced. See Flow execution details.
- Flow error handler
- A flow error handler enables a flow to catch and report errors from the flow execution details. Run a sequence of actions and subflows to identify and correct issues. For example, have flows log output values, send notifications, and run corrective subflows when they produce an error. See Flow error handler.
- Subflows
- A subflow is an automated process consisting of a sequence of reusable actions, data inputs, and outputs. In contrast to flows, subflows do not have a trigger but instead run when called from a flow, from another subflow, or from a script. Building and managing subflows requires that you have some familiarity with the ServiceNow AI Platform tables and fields that the application or process uses. Process analysts can create subflows using available actions or use an existing subflow as a template. See Building subflows.
- Actions
- An action is a reusable operation that enables process analysts to automate ServiceNow AI Platform features without having to write code. For example, the Create Record action allows process analysts to generate records in a particular table with particular values when certain conditions occur. ServiceNow core actions like Create Record require some familiarity with ServiceNow AI Platform tables and fields. Action designers can create application-specific actions to pre-set configuration details. For example, creating a Create Incident Task action ensures that the process analyst uses the correct table and field configuration each time the action is used. You can add application-specific actions by activating the associated spoke. See Workflow Studio actions.
- Spokes
- A spoke is a scoped application containing Workflow Studio actions and subflows for managing specific tables. For example, the ITSM Spoke contains actions for managing Incident and Problem records. You can activate additional spokes from the ServiceNow Store or activating the appropriate plugin. Building your own spoke requires familiarity with application development on the ServiceNow AI Platform. For a list of available spokes, see Spokes.
For detailed instructions for creating a flow, see Create a flow in Workflow Studio.
Sections of a flow
A flow consists of four sections.
- 1. Trigger section
- The Trigger section is where you select and define when the flow runs. Each trigger type defines when a flow starts and the starting data available to it. There are triggers for record operations, dates, and application operations.
Flows support record-based, schedule-based, and application-based trigger types. For more information about available trigger types, see Workflow Studio flow trigger types.
- 2. Action section
- The Actions section is where you select and configure the steps that make up your flow. You can add actions, flow logic, and subflows to a flow by opening the associated picker.
Sequential numbers appear next to each item in the design canvas. Action numbers start with 1 and then increment by 1 as you add more items to the flow.
- 3. Error handler section
- The Error handler section of the flows is where you can enable the flow to catch and correct errors. For more information about using the error handler section, see Flow error handler.
- 4. Data panel
- The Data panel stores any data gathered or generated by the flow as variables. Each data variable has its own pill that Flow designers can use to drag the variable value to an action input or output. Flows generate the
pill name based on the contents and its data type. The system specifies the variable data type next to the pill.
Figure 1. Example flow data in the data panel
Action configuration
Add an action to a flow by opening the action picker. Configure an action by specifying its input values, which may be data from the flow trigger or the output of other actions. Enter values for inputs directly, or use data from the Data panel to configure an action's inputs. At the start of a flow, the data may be limited to the flow trigger or subflow inputs. As you add actions to a flow, the output values of each action appear as data pills in the Data panel.
Component pickers
In the Actions section of a flow, you can select the Action, Flow logic, or Subflow options to open a picker for that component type. You can either enter text in the search window to search for a component, or browse the categories to find a component that you want to add to your flow.
The Action picker consists of several features to make finding actions easier.
- Search actions
- The Action picker filters the list of actions it displays as you type. The picker only displays actions that match your search query.
- Most recent
- The Action picker displays a list of the most recent actions that you have selected during this session.
- Popular
- The Action picker displays a list of actions that other users have frequently used.
- Installed Spokes
- Some applications include spokes which add application-specific actions. Spoke actions are typically read-only but can be copied and customized. The Action picker groups actions by the application scope that they belong to. Select
a spoke to see its list of actions.
- ServiceNow Core actions
- Your instance comes with a collection of core actions, or frequently used ServiceNow AI Platform operations, that can be added to any flow.
- Global spoke actions
- Developers may create custom actions in the Global application scope to make them available to all applications. ServiceNow provides some actions in the Global scope for use in any flow.
- Custom actions
- Developers may also create custom actions in an application scope that they own. Custom actions appear in the action picker under the application scope of the spoke.
Descriptions of flow data
See a natural language description of the data each component of a flow uses. Understand what data flow triggers, actions, and flow logic blocks use without having to open their configuration details.
- Trigger description
-
The create record trigger describes the conditions that must be met to start the flow.
Incident Created where (Short description starts with [demo], and Assigned to is not empty )
- Action description
-
The Look Up Records action describes the filter conditions it uses to find records.
Look Up Incident Records where (Caller is [Trigger - Record Created > ... > Caller], and Active is true)
- Flow logic description
-
The If flow logic describes the conditions which must be met to run the actions it contains.
If [1 - Look Up Records > Count] is greater than 1
Flows benefits
- Automates repetitive work to improve efficiency and experience.
- Describes a workflow in natural language to help non-technical users understand what it does.
- Displays a workflow as a diagram to help builders see available paths and connections.
- Enables creating and testing a workflow from a single interface to ensure it works as expected.
- Promotes process automation by enabling subject matter experts to develop and share reusable actions with flow authors.
- Reduces upgrade costs, with upgrade-safe ServiceNow AI Platform logic replacing complex custom script.
- Reduces development costs by providing a library of reusable actions.
- Scales with separate subscriptions for integration and Robotic Process Automation (RPA) functionality.
| Benefit | Feature | Users |
|---|---|---|
| Build an automated workflow from an existing library of automated operations. | Flow | Application developer, process owner, or administrator |
| Run an automated workflow when a set of trigger conditions are met. | Flow | Application developer, process owner, or administrator |
| Use a set of trigger conditions as input data to run an automated workflow. | Flow | Application developer, process owner, or administrator |