Using Runtime Selection

Overview

The 'Runtime Selection' feature on the Sub Flow step allows running a Flow dynamically based on specific runtime conditions. This eliminates the need for adding multiple Sub Flows to the Primary Flow, reducing the overall design time.

Use Case

Suppose you have a process that involves collecting customer feedback on a product or service. Depending on the type of feedback (e.g., positive, negative, neutral), you want to route it to a different team for further action. Each team has a different set of rules and procedures for handling feedback.

To accomplish this, you create three separate Flows, each with its unique set of rules and procedures but with the same Input and Output names. At runtime, the process determines the type of feedback and selects the appropriate Flow ID based on that input. The selected Flow is then executed, and the output is returned to the primary process for further processing.

As a result, there is no need to map all the Sub-Flows within the Primary Flow, which would complicate the design and require additional time. This approach simplifies the overall design and minimizes processing time. 

The following table clarifies Flow terminologies that will be referenced later in the article. 

Enable Runtime Selection

1. Navigate to the Sub Flow step.
2. From the Properties Panel > Advanced > Selection Type > Select Runtime Selection from the drop-down.
3. From the Properties Panel. Under the Input Section, a new field called Target ID will get exposed.
   

How Runtime Selection Works

Passing Target ID to Sub Flow

In the Primary Flow, users must build a Logic that dynamically passes the Target ID to the Sub Flow Step during runtime. This logic can be easily built using a Truth Table.

Dynamic execution of Flows 

Once the Sub Flow Step receives a Target ID, it will run the Target Flow at runtime. However, if the Sub Flow does not receive any Target ID, it will run the Template Flow that was picked during the Design Time.

Thus, either the Template Flow or Target Flow will run during runtime.

Relation between the Template and Target Flow

The Template Flow and the Target Flow must exhibit identical behavior. All the Target Flows depend on the Template Flow, meaning that if the Target Flow is designed to run Async and the Template is not, then the Target Flow will not run and will throw an exception of Invalid Runtime Switch.

E.g., if any Target Flow has a Form, the Template Flow has to have one even if it doesn't get hit.

Passing Inputs and Outputs to/from Target Flow

The Sub Flow step will pass all the input parameters of the Template Flow to the Target Flows. Hence, users must ensure that the input and output Data Type and Name for all Target Flows are the same as the Template Flow. To use the same input and output for all the Sub Flows, users can use Design Pattern.

Sending Dynamic Inputs to the Target Flows

The 'Additional Data for Flow' feature allows the Sub Flow to add extra input parameters. These additional input parameters can pass data directly from the Primary Flow to Target Flows.

1. From the Step Properties > Advanced > Additional Data for Flow.
2. Click on the "Add" button to open a dialog box for adding additional data to the Flow. Use the information provided in the table to configure the dialog.

   Property Name	Description
   Output data name	Name for the data.
   Data type	The data type for the data.
   Can be null	Allows the data to have a null value.
   Is list	Defines the data as a List.
   SelectEditor	Allows the user access to the PropertyEditor selector, enabling users to select from a drop-down list of properties that can be applied to the data.

3. This will add a new input parameter under the INPUTS section.

Example

The following example provides a simplified explanation of how runtime selection operates.

The example involves building a Flow that enables users to input the type of loan (such as Home Loan, Car Loan, Personal Loan, etc.), and based on the specified loan type, a corresponding Sub-Flow will be executed.

All the Sub Flows contain a Show Popup Step that will show all the details filled in the input while debugging the Primary Flow.

Create Sub-Flows

1. Create a Flow (Home Loan), and add inputs (Amount, Name, and Loan Type) via Setup Input Data. 
2. Add a Show Popup step to the Flow. Give a constant Subject and map the inputs to the Message via Merge HTML Text.
3. Similarly, copy the Flow and create another 2 Flows, i.e., Car Loan and Personal Loan. Copy Flow IDs of all the 3 flows for future reference. (right-click > manage > Get Flow ID).
   

Create Truth Table

1. Create a Truth Table in the Designer Folder and set the configuration to match the input value with the Flow ID.
   

Add all to Primary Flow

1. Create a Primary Flow in the Designer Folder. Add the inputs to the Flow similar to the Target Flow. Add the newly created Truth Table and a Run Sub Flow Step. Enable the Runtime Selection on the Run Sub Flow Step. Pick any one of the Sub-Flows (e.g., Home Loan) as a Template Flow.

Mapping

1. Map the input of the Truth Table and the Sub Flow Step with all the input parameters.
2. Map the Results of the Truth Table to the Target ID of the Sub Flow step.

Debug the Flow

Based on the user input, the Truth Table will pass the Target ID to the Sub Flow step running the Target Flow, and all the details filled will be passed to the Show Popup step (Target Flows). The example demonstrates how different Sub Flows can be triggered dynamically based on user input.

Troubleshooting Common Errors

1. Invalid Runtime Switch
   This error may pop up when any of the Target Flows uses an Async step while the Template Flow is not. As mentioned above, the Template and the Target must exhibit identical behavior.
   
   To resolve this issue, users must use Async steps in the Template flows or convert Target Flow to the synchronous Flows. For more information, refer to Asynchronous Steps.
2. Not Able to run the Target Flows
   
   To run the Target Flows successfully, it is essential to pass the correct values to the logic (Truth Table). In the above example, any spelling errors in the "Loan Type" will not match the values from the Truth Table, and thus it will not pass the Flow ID to the sub-flows, which will eventually run the Template Flow.