FAQ Refactoring Flows

Overview

This Document covers questions regarding changing to Flows that are In-Flight. In-Flight FLows are Flows that have been run and an assignment has been sent out. The Assignment is in-progress or not completed yet. Certain changes to a Flow can be safe while others can cause problems.

Decisions Refactoring Flows FAQ

Q: Can users add Steps/ remove Steps?

A: When Steps are removed or added to a pre-existing Flow, any in-flight Assignments will reflect the change; new Assignments will also reflect the change.

Q: Can users Remove Assigned Forms?

A: If an assigned Form is removed from the Flow, users will not be able to open any Assignment that uses that Form that is already in-flight. Also, there will be a validation notification letting users know that the Form is being used before the user can remove it from the Flow.

Q: Can users move Steps to a Subflow?

A: Yes, steps can be moved in a sub-flow. However, the input and output mapping needs to be configured properly to prevent any errors. It is also a best practice to use sub-flows for logic that is used repetitively throughout the process. It helps with organization.

Q: Can users move steps from a sub-flow back to the parent Flow?

A: Users can move steps from sub-flow back to the parent Flow but should do so with caution. When steps are moved from the sub-Flow to the parent Flow, users will need to reconfigure the mapping for the steps that were using the output from the sub-flow. Reconfiguration is needed in cases where the variable names have changed. These inputs should now be mapped directly to the steps that were moved into the parent Flow from the sub-flow.

Q: Can users add a property to an entity if there's an assignment on an entity action Flow?

A: The impact varies for this change. If the property is added and not used for the action Flow then there will not be any errors. When the added property is used in the Flow, the value for it will be nulled for the in-flight assignments. This will throw a validation error. 

Q: Can users remove a field from a Form that is assigned?

A: Form Components can be removed from a Form that is assigned. The changes will be applied to the assignment in Flight. The removal of the component from the Form will remove an output from the Form step in the Flow that uses it. Even though the assigned user will see the applied changes if that output was being used as an input for another step in the Flow than it will cause issues as that outcome variable will be Null.

Q: Can users add a field to a Form that is assigned if output only is set?

A: Fields with "Output Only setting" can be assigned to Assigned Forms. The New field will appear on the Form for in-flight tasks. However, if the output of this field is used as an input for any other fields, this change will not be applied to tasks in-flights. This change will occur for new tasks that are assigned.

Q: Can users remove a property from an entity?

A: 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, the assignment in-flight will not throw any errors but the assignment will show null values.

Q: Can users add output from a sub-flow back to a parent Flow? (assignment in a child, assignment in the parent)

A: This change will not be applied to assignments in-flight. This change will only be applied to new assignments that are sent after this change. The in-flight assignment will apply the original logic.

Q: Can users add a Branch to a branch step?

A: Any new branch added to the Branch Merge steps will not impact the Assignments in flight. The new assignment added to the new branch will not apply to the current in-flight assignments. It will only apply when the Flow is run again after the change.