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 can become stuck or canceled due to a deleted or modified step or stage. For example, assume you have a flow where a case 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?
Failure to consider open work objects while progressing through updated flows can result in problem flows, stuck work objects, assignments in error, orphaned assignments, and other errors.
By properly planning your strategy for upgrading production flows, in-flight cases will be properly accounted for and the upgrade will be seamlessly integrated.
Possible reasons for problem flows
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:
- A step is removed in which there are open cases. This change causes orphaned assignments.
- A step is replaced 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.
- Wait points are removed or replaced 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 the active subflows.
- A stage is removed from a case life cycle, and there are in-flight cases in the removed stage. In-flight cases cannot continue the case life cycle.
Parent flow information that affects processing
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:
pxTaskLabel – The developer-entered text label of the assignment shape.
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
This Topic is available in the following Module:
Want to help us improve this content?