Refactoring In-Flight Flows

Overview

Long running or In-Flight Flows are Flows that are active and have an Assignment but have not yet reached a completed state. Due to this, certain changes to a Flow can alter how data is handled, which may produce errors and unintended results. 

The below document outlines some common changes to In-Flight Flows and the potential risks.

Understanding Persistence Behavior

When identifying safe changes, it is helpful to understand persistence behavior.

Each time a Flow executes an assignment step, Decisions will save the Flow’s current state and then stores this data to the database. All immediate parent Flows are also stored. 

The assignment step triggers this event because it has persistence behavior, and the result is what is called a “stored” or Long-Term Flow.

This allows the Flow to idle indefinitely until the assignment is worked again, at which time Decisions retrieves the "stored" Flow’s execution data from the database so that execution can resume.

It is helpful to understand what is included in this “stored” flow, and what is not:

What is stored:

The design/configuration of the Flow that the assignment step is in

If the assignment is in a Subflow, then all immediate parent Flows are also stored

This includes:

What steps are used and their location in the Flow

Step mappings (“Select from Flow”, “Constant”, etc) and any other step properties

Any data that was handled in the flow’s execution leading up to the assignment

If the assignment step is in a Subflow, then all immediate parent flows are also stored

What is not stored:

The current configuration of any Designer Entity, such as form/rules/reports/etc called by the Flow (including other Subflows). When the Flow references any of these resources, they are called live (a.k.a. “by reference”).

Any Subflow that does not contain the active assignment and is not a parent of a Subflow that contains an active assignment.

Changes that can affect in-flight Flows

Any change that has been described here as “not stored”; especially changes made to Designer Entities (forms/rules/flows/reports/etc.)

This is because when a stored Flow resumes execution, these resources are called live (a.k.a. “by reference”).

If a developer removes, adds, or modifies any input or output on a Designer Entity, then the Flow will not be aware of these changes, causing conflict because the Flow will expect to use its “stored” mappings, but the Designer Entity will use the new inputs or outputs.

Changes that do not affect In-flight Flows

Any changes that have been described here as “stored” should not be vulnerable.

Any Subflow that will execute after the assignment is completed is vulnerable to changes.

Steps

Adding/Removing Steps

When Steps are removed or added to a Flow, any in-flight Assignments will not process the changes and instead will run the original Flow with no validation errors. Any Assignments sent after will include the changes.

Adding Branches Using a Branch Step

Any new branch added to a Branch Merge steps will not impact in-flight Assignments in. New Assignments added to a new branch will not apply to currently running Flows, but will apply to new Flows.

Subflows

Adding New Inputs/Ouputs on Subflows

If additional inputs/outputs are added to a Subflow that did not exist previously, then the data will not exist for the active Flow. 

In order to ensure that these changes can be used by actively running Flows either:

1. Initialize new data between areas in the Flow that may be paused/where the data is needed. Do NOT initialize the data before an Assignment if it is used in the process after the Assignment.

or

1. Navigate to System > Administration >  System Tools > Flow management> Stored Workflow page.
   
2. Click on the Flow name. A new page will open. 
3. Select the Flow that needs the change from the Stored Workflow List.
4. Under Selected Flow Step Details, right-click Current > Edit Flow Data and add the data to the correct field. 

Outputs will not be applied to assignments in-flight. This change will only be applied to new assignments that are sent after this change. In-Flight Assignments will apply the original logic.

Moving Steps into Subflows

Steps can be moved into a Subflow, but current input and output mapping will be reconfigured to prevent errors.

Users can also move steps from a Subflow back to the Parent Flow, but should do so with caution. When steps are moved from the Subflow to the Parent Flow, users will need to reconfigure the mapping for the steps that received output from the Subflow. 

Reconfiguration is also needed in cases where the variable names have changed. 

Forms

Adding New Fields to Forms

Newly added data may not be initialized after an Assignment if it comes from a previous Form or shown on an Active Assignment. Only the most current version of a Designer Element, in this case a Form, will be used. 

If the Assigned Form is still in-flight while the change is made, then the newest version of the Form will load, which may result in different output data. In order to ensure the data will be preserved:

• Make Form Fields editable; if new data doesn't exist in a Flow yet, allow users to input it themselves.
  
  
• Make sure that a field on a Form is never both Required and Disabled; ensure that if a field's input is required, that the field is Enabled via the Properties tab.

Replacing Assigned Form Steps with New Forms

Removing Assigned Forms from an in-flight process will throw an exception error due to the ability to complete a previously requested Assignment.

To prevent errors, update existing Forms rather than replace them with new versions. Below are two methods for ensuring in-flight assignments complete.

1. Leave the original Assignment Step in the Flow with its Outputs connected and route the Flow to the new Assignment. Once any/all in-flight processes have moved past the original Assignment step, remove it from the Flow. Only use this method on minor Flow changes, utilize other methods for larger changes.
   
   
2. Copy the original Flow, and make the changes. Keep the original version of the Flow containing deprecated functions to allow any in-flight processes to finish up. Any new processes will be handled within the new version of the Flow. Utilize this method for major Flow changes.

Removing Assigned Forms

If an assigned Form is removed from a Flow, users will not be able to open any inflight version of this Assignment. There is a Validation Notification informing that the Form is being used before the user can remove it from the Flow.

Removing Form Controls

Form Controls can be removed from an assigned Form. and the change will be applied to In-Flight Assignments. Removing the control will remove its output from the Form step. Assigned users will see applied changes, but if the output is used in a later step in the Flow, then a null value will be passed.

Adding Fields to a Form

Form fields with Output Only setting enabled can be added and will appear for In-Flight Assignments. However, if the output of this field is used as an input for any other fields, the change will only occur for newly created Assignments.

Entities

Adding/Removing a Property

For this change. If the property is added and not used for a Flow then there will not be any errors. If the property is used in a Flow, then the value will be nulled for in-flight Assignments and throw a validation error. 

If a Property is removed from an entity, the impact will depend on how that entity was being used. For instance, if an entity is being fetched and used as an input for another step, then any in-flight Assignment will have errors since the input will be null. 

If the entity is fetched and it is only used for displaying, then the Assignment will not throw any errors but will show null values.