Refactoring In-Flight Flows
  • 27 Jun 2022
  • 4 Minutes to read
  • Dark
    Light

Refactoring In-Flight Flows

  • Dark
    Light

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.


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.


For further information on Flows, visit the Decisions Forum.



Was this article helpful?