Workflow Studio is the default ServiceNow AI Platform process automation builder used to create flows. Workflow Studio replaces the Workflow Editor.

Flows consist of a trigger and a sequence of actions and flow logic. When you add actions and flow logic to a flow, the data collected or created appears in the data panel, which you can use in other actions and flow logic.

Building and managing flows requires that you have some familiarity with the ServiceNow AI Platform tables and fields that the application or process uses. Process analysts can create flows using available actions and flow logic, or they can copy an existing flow to use it as a template.

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.

More Actions menu

Select the More Actions icon (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 Workflow Studio 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.

Printing flows

Workflow Studio 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 Workflow Studio, make sure you understand how existing ServiceNow AI Platform automations work. Deactivate automations before replacing them with Workflow Studio flows and actions. See the Architecture Overview to learn how Workflow Studio 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.