Modifying In-Flight Flows

Overview

Though Process Folders, Process Logic, Flow Execution Extensions, etc can be used to handle long-term processes, users must consider the possibility of future updates or adjustments. A customer may require new features (such as new Steps or Rules) be added to the process that may affect how the whole process operates.  By altering any part of the process Designers are thereby changing how the in-flight data is handle, and this may produce errors or unintended results. It is important that users understand the potential risks of changing long-running Flows that are actively in production. The following document discusses some of those pitfalls and potential solutions to help users build more effective processes.

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 doesn’t 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/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/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.

Common Issues Modifying In Flight Flows

The following is a list of common issues with modifying an In-Flight Flow, and their solutions. 

Adding new Inputs on Subflows

If additional data is added to a Subflow that does not exist within the in-flight process, the data will not exist in the memory of the in-flight process.

ie: initializing new data that is used after an Assigned Form, before the Assignment.

Solution: 

• 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.
• Use the Flow Management Tools to update the in-flight process with the newly required data.

Adding new Fields to Forms

Newly added data may not be initialized after an Assignment if it comes from a previous Form or must be shown on Active Assignment. Decisions uses the most current version of a component (in this case Form), therefore, if an Assigned Form hasn't been completed yet when a user goes to work that Assignment, the newest version of the Form will load. The fields on this Form may differ from the previous version, resulting in different expected Output data.

Solution: 

• Make Form Fields editable; if new data doesn't 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.

Solution:

• Where possible, update existing Forms rather than replace them with new versions.
• Leave the pre-existing 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.

• Copy the original Flow, then make adjustments within the copied version of the Flow. 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. 

• Provide a new Name for the new version of the Flow, do not Name the new version [FLOW NAME] V2