Building flows

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 consist of a trigger and a sequence of actions. When you add actions to a flow, the data collected or created appears in the data panel, which you can use in other actions.

Triggers

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.​

Flow Designer supports record-based, schedule-based, and application-based trigger types. For more information, see Flow Designer trigger types.

Actions

Within Actions, flow designers can add actions, flow logic, and subflows to a flow.

Actions are reusable elements that perform repeatable operations. 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.

Action picker

In the ACTION section of a flow, select Add an Action, Flow Logic, or Subflow > Action to open the action picker. You can either enter text in the search window to search for an action, or browse the action categories to find an action that you want to add to your flow.

Action numbering

Sequential numbers appear next to each item in the Flow Designer interface. Action numbers start with 1 and then increment by 1 as you add more items to the flow.

Note:

If you upgraded from a prior release, your inline scripts may still contain references to legacy flow action numbering. See Flow action numbering to automatically update these references for your flow.

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.

Spoke actions

Some applications include spokes which add application-specific actions. Spoke actions are typically read-only but can be copied and customized.

Custom actions

Developers may also create their custom actions from the Action Designer interface.

Action limit

By default, flows can have no more than 50 actions. To change the default behavior, increase the value of the sn_flow_designer.max_actions system property. However, consider the performance impact that a large flow may have on your instance.

Missing actions

If an administrator added your flow from an update set, you might have some missing actions in your flow. This normally happens when your instance doesn't have the appropriate Integration Hub spokes installed. For more information on how to install the spokes you need to get these actions to appear, see spokes.

Data panel

Flows store any data gathered or generated as variables in the data panel. Each variable has its own pill that Flow designers can use to drag the variable value to an action input or output. Flow Designer generates 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

More Actions menu

Select the More Actions icon () to access additional options for your flow.

Stages

Access the stages for a flow.

Manage flow catalog variables

Manage the catalog variables available to Service Catalog-triggered-flows.

Flow Variables

Create flow variables to set and retrieve data throughout a flow.

Copy flow

Create a copy of the open flow in an application you specify.

Flow preferences

Enable or disable the Show draft actions, Show triggered flows, Show store spokes, and Show inline script toggle options.

Create code snippet

Generate a code snippet to call a specific flow, subflow, or action.

Manage security

Enable or disable the Callable by Client API option.

Change default flow title

Change the default title for your flow by adding styled or dynamic text. For more information, see Create a natural language title.

Testing flows

You can test a flow directly from the Flow Designer interface. Each test runs your flow as if the trigger conditions were met. If the flow has record trigger, you can specify the record to use for your test. After the flow runs, use the flow execution details to verify that your flow is running properly.

Important:

Always run tests on a non-production instance where flow record changes cannot interfere with your production data.

Flow execution details

Each time you test a flow, the system generates flow execution records, log messages, and reports. The flow context is a related record containing the current state and runtime values of the flow. The system generates a context record each time a flow is run.

Optionally, you can configure the system to generate execution details anytime a flow is run, not just during testing. For more information, see Activate flow reporting.

Flow properties

The flow properties contain information about your flow. In the main header, select Properties to view or edit your flow's properties.

Property	Description
Name	Enter a unique name for the flow
Protection	Choose whether the flow is read only by choosing from None or Read-only
Application	Select an application for the flow. This property is set when creating the flow and cannot be changed afterwards.
Description	Enter a description of the flow.
Run As	Option to specify the user that runs the flow. You can select the system user or the user who initiates the session. Select the user who initiates the session option when updates should come from the user who triggered the flow. For example, use this option when you want the incident record comments to come from the user who started the flow. Settings for the Run as option in a flow don't apply to child subflows. To create a flow that can run with a personal OAuth token, select the user who initiates the session option. If the user who is running the flow has a personal OAuth token, the flow runs with that token. For more information about creating a personal OAuth token, see OAuth 2.0 credentials.
Run with role(s)	Roles that the flow runs with. This option is only available when Run as is set to user who initiates the session.

Printing flows

Flow Designer supports multipage printing for flows, subflows, actions, and flow execution details. For a list of supported browsers, see Browser support.

Roles

To access Flows, a user must have the flow_designer or admin roles.

General guidelines

Flows should be short, modular, reusable collections of work. If they take more than an hour to execute, they’re probably too long and can be more efficient.

Any general guidelines that apply to flows also apply to subflows.

Prevent conflicting or duplicate business logic

Automations can be created with Flow Designer, business rules, workflows, and Integration Hub. Before you start using Flow Designer, make sure you understand how existing ServiceNow AI Platform automations work. Deactivate automations before replacing them with Flow Designer flows and actions. See the Architecture Overview to learn how Flow Designer works within the ServiceNow AI Platform.

Review Flows, Sub-flows, and Actions documentation, if necessary.

Determine whether your flow needs a trigger or variable input

Flows always run when their trigger conditions are met. Triggers always provide the same data as input for flows. If you need variable input to initiate a flow instead, create a subflow.

Reuse business logic

Create a set of reusable operations as a subflow that can then be used in multiple flows.

Grant flow roles to access role-protected data and preserve user information

Flow roles help keep permissions for your flows simple. Use flow roles to preserve user information and grant access to data, instead of running a flow as the system user. Adding flow roles also gives access to additional data that a user-initiated flow does not usually have. The roles granted only apply to the flow. They do not apply to the user who initiated the flow.

Use flow logic or a schedule-based trigger to control flow timing

Flow logic or schedule-based triggers help to optimize the performance of your flows. Do not use the gs.sleep() method to wait within a flow. The gs.sleep() method prevents the thread from performing other work. To run a flow at a specific time, use a schedule-based trigger. To pause a flow for a specific duration, use the Wait for a duration or wait for condition flow logic.

Avoid dependencies

Parallel branches that depend on each other stall a flow when a branch has to wait for output from another branch.

Scope loop counters

Script loops don't have a maximum number of iterations, so loops execute infinitely when there is not a valid exit condition.

To make sure that there is a valid exit condition, use scope loop counters in inline scripts or in script steps within an action. Add var tofor (i=0; i< length; i++) and get for (var i=0; i< length; i++)

Limit For Each and Do Until loops to 1000 iterations

Iterations with 1000 or more loops can lead to memory issues.

• Set max records on Look Up Records to 1000.
• Avoid changing property sn_flow_designer.max_iterations, which defaults to 1000.
• For large amounts of data processing, consider batching into smaller batches.
• For bulk imports, consider concurrent imports.

Use QuickAPI for faster executions (business rule alternative)

• QuickAPI executions are much faster, but there is less debugging capability.
• Foreground QuickAPI executions run in the user session as the user who called the flow.
• Background QuickAPI executions run in a background thread and are run in the ‘system’ user session.

Use Do Until loops instead of calling flows from themselves

A flow calling itself is not allowed and errors out. But if flow A is calling flow B, then flow B can call flow A up to three times.

Execute flows in the background

Executing flows in the background enables UI threads to be released rather than keeping users waiting for flow executions.

Avoid flow logic that waits after collecting a large output

Using a large payload immediately after it is retrieved can help prevent memory issues.

Minimize switching between environments

Constantly switching back and forth between instance and MID Server steps in a flow can lead to delays in processing. To minimize the risk of delays, limit switching between instance and MID to only one time.

Include sys_complex_object records generated by the flow in update sets

Missing complex data schemas can cause execution issues. Make sure you include sys_complex_object records generated by the flow in update sets.

Calling flows from a script

Start flows with a custom trigger by calling from a script.

Avoid deploying newer release flows to instances on older releases

Workflow Studio does not support deploying newer release flows to instances running on earlier releases.

Danger:

The flow data model can change between releases, which can prevent newer flows from running or produce unexpected results when running on earlier release instances. Upgrade your instances to be on the same release versions before deploying them.

Turn flow reporting off in production

Minimize the amount of memory required to run flows by disabling Flow reporting. Flow reporting stores configuration and runtime information for the Execution Details page. These reports are good for troubleshooting, but requires a large amount of data to be retained both in memory and in the database. By default, flow reporting is disabled, and the system only generates execution details when you manually test a flow or action. Instead you can use log files, which are still available when reporting is turned off.

Reduce the amount of memory consumed in flows with nested looping

When reporting is activated, set com.snc.process_flow.reporting.iteration.lastn to a value of "1" to reduce the amounts of the amounts of memory that previous loop iterations consume. The more iterations you report on, the more memory is required.

• Create a flow
  Run one or more actions when a trigger condition occurs.
• Flow and subflow stages
  Communicate the current stage of a request, flow, or subflow with an end user.
• Flow error handler
  Enable flows to catch errors. 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.
• Flow Template Builder
  Enable citizen developers to create their own flow templates. Flow Templates guide flow authors to create flows for common use cases. Use the flow template builder to define flows, actions, and flow template variables.
• Flow variables
  Similar to Workflow scratchpad variables, create variables that you can use and modify directly in your flow. Access flow variables as data pills directly in the Data panel.
• Inline scripts
  Enable users with coding experience to write inline scripts that set and modify input values during the configuration of an action or flow. Use inline scripts to modify input values that require small format conversions, data transformations, or math operations.