Flow changes for Cases in flight 

Business processes frequently change. These changes can impact cases that are being worked on. Without proper planning, these in-flight cases could become stuck or canceled due to a deleted or modified step or stage. For example, assume you have a flow where a cases goes from a Review Loan Request step, then to a Confirm Request step, and then to a Fulfill Request step. If you remove the Confirm Request step during a process upgrade, what happens to open cases in that step?

By properly planning your strategy for upgrading production flows, in-flight cases will be properly accounted for and the upgrade will be seamlessly integrated.

Since flow rules hold assignment definitions, altering a flow rule could invalidate existing assignments. Following are examples of why a problem may occur in a flow:

• You remove a step in which there are open cases. This change causes orphaned assignments.
• You replace a step with a new step with the same name. This change may cause a problem since flow processing relies on an internal name for each assignment shape.
• You remove or replace other wait points in the flow such as a Subprocess or a Split-For-Each shape. These changes may cause problems since their shape IDs are referenced in active subflows.
• You remove a stage from a case life cycle and there are in-flight cases. In-flight cases are not be able to change stages.

Run-time flow processing relies on flow information contained in assignments. Changing an active assignment's configuration within a flow, or removing the assignment altogether, will likely cause a problem. Critical flow-related assignment information includes:

pxTaskName — the shape ID of the assignment shape to which it is linked. For example, Assignment1

pyInterestPageClass — the class of the flow rule. For example, FSG-Booking-Work-Event

pyFlowType — the name of the flow rule. For example, Request_Flow_0