About Sync and Async Sub-Flows
  • 03 Jun 2022
  • 3 Minutes to read
  • Dark

About Sync and Async Sub-Flows

  • Dark


A Sub-Flow is a Flow that runs like a Step in 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:

  1. The Sync method: pauses the primary Flow until the Sub-Flow completes.

  2. The Async method: allows the the primary Flow to run independently, while the Sub-Flow completes.

Each method has benefits for use in different scenarios; part of your Flow design planning should be to decide which method works for your specific scenario. The key difference is that the Sync method will cause the primary Flow to remain in a wait state (i.e. keep running) until the Sub-Flow completes. The Async method tells the primary Flow not to wait for the Sub-Flow to complete. (In legacy versions of Decisions, the Async method is called the "Fire and Forget" method.) With Async, 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 its primary Flow. Due to the Flow running asynchronously, the Sub-Flow in an Async Flow, does not return data to the parent Flow, as opposed to a Sync Flow, which does. 


Async Flows

In the screenshot below, the gray-colored Process Flow is a Fire and Forget Linked Flow Async step. In this example, the Sub-Flow is designed to be ran separately from the primary flow. Whenever an email is found, it is sent to the process workflow to be filtered by a user set rule. In this case, it makes sense to use the Async method because it allows the primary flow to check for Emails, while the child flow, processes each one individually.

Much like in the example above, Async flows are helpful for processes that deal with a large number of items, ie. having to review a large volume of loan applications.


Start Linked Flow Async

The Start Linked Flow Async is a flow step that allows a user to run a sub-flow independent of its parent process.  Below is a table description of the step and a screenshot.

Used Frequently
Please note that there are multiple ways to run a process async, but the Start Linked Flow Async is the most used step by decisions developers to achieve this.
OptionFunction Description
Selection Type Decisions can run a flow picked by a user or can be dynamically selected by runtime
Use Work QueueFlows execution can be passed onto a work queue to be handled e.g. rabbitmq. For more info on work queues review worker queues workers threads
Manage Execution ThreadsThe user can select which thread to run this process on, potentially used in multi-tenant environments

Run Flow Async And Wait

The Run Flow Async And Wait is a check box configuration on the Run Flow, flow step.  This configuration does not run the sub-flow independent from the parent process but executes it on a separate thread. This check box configuration does three thigns it: spawns a new process, runs the flow synchronously, and waits for the sub-flow to return data. One difference between the run flow async and wait step and the Start Linked Flow Async is, 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

There is also a Go Async flow step. This step will make every flow step after it run independently. For more information review Running Steps Asynchronously With The Go Async Component.

Synchronous Flows

Sync flows are helpful for handling processes that require the main flow to be paused. For instance, within the Async flow above, the Email handling process is split up into multiple synchronous subflows 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 type, and sent to its respective subflow. This  allows for the ability to pause the flow before proceeding to the next step. 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 troubleshooted, as they are split up separately. 

Was this article helpful?