Flow changes for Cases in flight 

Modifying a flow can invalidate existing Assignments because flows define Assignment behavior. The following scenarios can 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 that has open Cases, the removal can result in orphaned Assignments.
• Replacement of a Step: If a new Step with the same name replaces an existing Step, the replacement can cause problems because 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, the change can cause problems because the system references their shape IDs in the active subflows.

When the system creates an Assignment during flow processing, Pega Platform automatically populates several key properties that establish the Assignment identity and context. Understanding each of these properties helps you anticipate the downstream effects of flow modifications.

During run‑time flow processing, Assignments contain flow information that is critical to the process. If you modify the configuration of an active Assignment in a flow or remove the Assignment altogether, you can introduce issues. The following properties represent critical flow‑related information for Assignments:

• pxTaskLabel represents the human‑readable text label that developers assign to Assignment shapes during flow design. This is the label that case workers see in their work queues, which helps them identify the nature and purpose of each Assignment. For example, you might label an Assignment as Review Credit Application or Approve Budget Request. While this label provides user‑facing clarity, it is important to note that changes to pxTaskLabel do not break existing Assignments because the system uses other properties for technical linking.

• pxTaskName serves as the unique shape identifier that Pega Platform uses internally to link work items to specific positions in the flow. When you add an Assignment shape to a flow, the system automatically assigns a technical identifier such as Assignment1, Assignment2, or Approve1. This identifier becomes the critical reference point. Unlike pxTaskLabel, which is primarily for human readability, pxTaskName is what the system uses to locate Assignments within the flow structure. When you modify or remove Assignment shapes, any in‑flight Cases that reference those pxTaskName values lose their connection to the flow and can trigger problem flows or create orphaned Assignments.

• pyInterestPageClass captures the class context of the flow itself. This property stores the full class path, such as FSG‑Booking‑Work‑Event or MyOrg‑Claims‑Work‑AutoClaim. The class context defines the Data Model and Rule resolution path for the Assignment, and it ensures that the system applies the correct Rules and accesses the appropriate properties during Assignment processing. If you restructure your application class hierarchy or move flows between classes, existing Assignments can reference class contexts that no longer align with your current architecture, which can lead to Rule resolution issues or Assignment routing failures.

• pyFlowType records the name of the flow that created the Assignment, such as RequestFlow or ApprovalProcess_Flow_0. This property enables the system to identify which specific flow is responsible for processing the work. When Cases have multiple flows that run in parallel or when subflows are involved, pyFlowType helps Pega maintain clear boundaries between different processing contexts. As with pxTaskName, modifications to flow names affect existing Assignments that reference the original flow name.

The system does not store the pzInsKey of the flow Rule (which uniquely identifies the Rule) by design.

When you plan a flow update, ask yourself the following questions:

• Am I changing any shape IDs? If you add new shapes, reorder existing shapes, or remove shapes, you are likely to change the auto‑generated shape IDs that Pega assigns. Any in‑flight Assignments that reference the old shape IDs become orphaned when you deploy the updated flow.
• Am I renaming the flow? Flow name changes break the pyFlowType reference for all existing Assignments. Even if the internal logic of the flow remains identical, the metadata mismatch can cause routing failures.
• Am I moving the flow to a different class? Class context changes affect pyInterestPageClass references. While the flow might run correctly for new Cases, existing Assignments can experience Rule resolution issues or routing failures because of mismatches in the class context.
• Am I making only configuration changes within existing shapes? If your modifications are limited to updating decision logic, changing flow Action configurations, or adjusting validation Rules without changing the flow structure, in‑flight Cases can continue processing seamlessly. This type of flow update is the safest option in production environments.

 Check your knowledge with the following interaction: