Skip to main content
Verify the version tags to ensure you are consuming the intended content or, complete the latest version.

Flow changes for Cases in flight 

It is important to recognize that business processes often undergo modifications, which can have repercussions on Cases that are currently in progress in your Pega Platform™ application. Without proper planning, these in-flight Cases might encounter delays or cancellations, particularly if a Step or Stage is deleted or modified.

Consider a scenario where a Case transitions from a Review Loan Request Step to a Confirm Request Step and subsequently to a Fulfill Request Step, as shown in the following diagram. If, during a process update, developers remove the Confirm Request Step, The open cases in the Confirm Request Step will become orphan, and there will be no connector path after the Confirm Request Step.

BeforeupdateAfterupdateWithBorder

Recognizing the importance of meticulously planning your strategy when upgrading production flows in an application or Case Life Cycle is imperative. Failing to consider open work objects can result in flow complications, such as:

  • Work objects becoming immobile
  • Assignments not being processed
  • Creation of orphaned or dangling assignments
  • Missing flow handles

By carefully strategizing the update process, you help ensure a smooth integration of enhancements, which accommodates in-flight Cases and averts potential interruptions. This approach highlights the importance of strategic planning in updating production flows.

Possible reasons for problem flows

Modifying a flow Rule might result in invalidating existing assignments since flow Rules hold assignment definitions. The following are scenarios that create problem flows:

  • Removal of a Stage: If you remove a Stage from a Case Life Cycle and there are in-flight Cases in the removed Stage, those Cases cannot continue the Case Life Cycle.
  • Removal of a Step: If you remove a Step with open Cases, this can result in orphaned assignments.
  • Replacement of a Step: If a new Step with the same name replaces an existing Step, this can cause problems since flow processing relies on an internal name for each assignment shape.
  • Changes in Wait points: If Wait points, such as a Subprocess or a Split-For-Each shape, are removed or replaced in the flow, it can cause problems because the system references their shape IDs in the active subflows.

Flow information that impacts processing

During run-time flow processing, Assignments contain flow information that is critical to the process. If you modify the configuration of an active Assignment that is in a flow or remove the Assignment altogether, you might experience issues. The following Rules are critical flow-related information for Assignments:

  • 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, Assignment 1.
  • 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.
Note: The system does not store the pzInsKey of the flow Rule (which uniquely identifies the Rule) by design.

 Check your knowledge with the following interaction:


This Topic is available in the following Module:

If you are having problems with your training, please review the Pega Academy Support FAQs.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega Academy has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice