About Sync and Async Sub Flows

Overview

A Sub Flow is a Flow that runs like a step within the course of another Flow. A Sub Flow may also be referred to as a Child Flow and the primary Flow as a Parent Flow.

A Sub Flow may be set to run in one of two ways:

• Synchronously via the Sync method: allows the Sub Flow and Main Flow to run sequentially.
• Asynchronously via the Async method: allows the primary Flow to run independently, while the Sub Flow completes.

Each type of Flow method has its own benefits for different scenarios. It is important to understand when building a Flow which method works for a specific scenario. The key difference is that the Sync method allows the Flows to run in sequence, whereas, the Async method is designed to allow the Sub Flow to run independently of the Parent Flow.

With an Async Flow, control is immediately given back to the primary Flow. The consequence of this method is that the relationship between the two Flows is "asynchronous", meaning that the Sub Flow is now an independently executing Flow and has no necessary output data to deliver to the primary Flow. 

Included below are a few examples and additional information, regarding the different types of Sub Flows.

Synchronous Flows

Sync Flows are helpful for handling processes that require the main Flow and Sub Flow to occur one after the other. For instance, within the Async Flow above, the Email handling process is split up into multiple synchronous Sub Flows depending on how the Email is evaluated. 

In the example below, after reaching the email Process Folder, an email is evaluated as either an invoice, resume, or other types, and sent to its respective Sub Flow. This allows for the ability to run a Sub Flow midway through the process, before proceeding to the next step and returning data to the Parent Flow. This can be especially helpful if manager approval or a user response is required in the process. It also allows each sequence in the Flow to be evaluated and easily troubleshot, as they are split up separately. 

Async Flows

Start Linked Flow Async

In the screenshot below, is a Sub Flow step called Start Linked Flow Async. In this example, the Sub Flow is designed to run independently from the Primary Flow. The primary purpose of Async Flows is for use in instances where the Primary Flow needs to delegate a task to the Sub Flow. Async Flows run as a System user and not the initiating user.

In the above example, whenever an email is found, it is delegated to the process workflow to be filtered by a user set Rule. In this case, the Async method allows the Primary Flow to check for emails, while the Child Flow processes each one individually.

The table below represents each of the available Properties provided by the Start Linked Flow Async step: 

Viewing Thread Jobs from Start Linked Flow Async Sub Flow

1. From the Decisions Studio, navigate to System > Administration > System Tools and open the Event Viewer.
   
2. Navigate to the Thread Jobs tab. Scroll to the bottom of the end of the Active Thread Jobs to view the Thread Jobs for the Subflow.
   

Start Linked Flow Async Flows in Multi-Node Environments

When utilizing a multi-node environment, Thread Jobs are not shared across the Server Cluster. Instead, they are completely discrete; this means that an Async Job that is started on one server will stay on and be executed on that one specific server. The information from these jobs is not shared across servers in any way. The load balance directs the work so that each server has its own specific Queue and Thread Jobs.

Run Flow Async And Wait

The Run Flow Async And Wait is a check box configuration on the Run Flow step.  This configuration does not run the Sub Flow independently from the parent process but executes it on a separate thread.  This option is used to spawn a new process, run the Flow on a separate thread, then return the data to the main Flow. This is helpful in scenarios that involve multiple steps that involve a loop or branch that would usually run synchronously, such as API calls or adding numbers. The Run Flow Async and Wait allows these tasks to be executed in parallel to save time.

One difference between the Run Flow Async and Wait step and the Start Linked Flow Async is that the Run Flow Async and Wait returns data while the Start Linked Flow Async does not return data. Run Flow Async and Wait is most commonly used to assist API calls that return large amounts of data. 

Go Async Flow Step

The Go Async step is used to move the current execution of the Flow to a different thread. This allows users more fine-tuning when it comes to directing which portion of a Flow is ran Async. Users may run portions of a Flow as Async without having to move the whole process.

Checking Flow Attribute 

In order to determine if a Flow is Sync or Async after it has been created without opening it, users may utilize the information provided by the Element Attribute in the Flow's PROPERTIES on the Info panel in the Flow Designer. This Property provides information on the selected Designer Element such as its Type, and the run behavior.
 
This information is located in the Information Panel that appears upon selecting any space within the Designer Project's Report row for that specific Flow. 

List of Async Steps

The following steps cause a Flow to go into an async state.