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

Managing flow changes for Cases in flight

There are several fundamental approaches to safely update the flows that are already in production. Because each application configuration and the business setting is unique, choose the approach that best fits your situation.

Caution: Whichever approach you choose, always test the assignments with existing cases, not just the newly created cases.

Approach 1: Move existing assignments

In this approach, you set a ticket that is attached within the same flow, change to a new stage, or restart the existing stage. In-flight assignments advance to a different assignment where they resume processing within the updated version.

You run a bulk processing job that locates every outdated assignment in the system affected by the update. For each affected assignment, bulk processing should call Assign-.OpenAndLockWork followed by Work-.SetTicket, pxChangeStage, or pxRestartStage. For example, you can execute a Utility shape that restarts a stage (pxRestartStage).

The following example shows a bulk assignment activity using SetTicket:

Move Assignment

After you have configured the activity, you deploy the updated flow and run the bulk assignment activity.

Caution: The system must be off-line when you run the activity.


In this example, a small insurance underwriting branch office processes about 50 assignments a day; most are resolved within two days. In addition, there is no overnight processing. You run a bulk process because the number of unresolved assignments is relatively small, and the necessary locks can be acquired during the evening. Note that it is not necessary to use the Commit method.

  • A batch process activity directs assignments by performing the logic outside the flow.
  • You do not need to update the flow by adding a Utility shape to the existing flow.
  • The activity enables you to keep the processing logic in the flow, makes upgrades easier, and also facilitates flow configuration and maintenance in App Studio.
  • It might be impractical if the number of assignments is large, or if there is no time period when the background processing is guaranteed to acquire the necessary locks.

Approach 2: Use dynamic class referencing

For case-specific rules, differentiation of a flow’s current state from its desired future state is accomplished using dynamic class referencing (DCR). 

On case creation, the value of the differentiating property, pxCreateDateTime, is established immediately. In combination with the differentiation value being set, the pxObjClass of the case is changed. The pyDefault data transform for the case can determine the current year using the following logic:

<var>Param.CurrentYear</var> = @toInt(@String.substring(@DateTime.CurrentDateTime(),0,4))

Then subsequently change the case’s pxObjClass by using the following logic:

.pxObjClass => .pxObjClass + "-Y" + Param.CurrentYear

Although this approach requires a class to be created for every year, it does not behave the same as as-of-date circumstancing.

One way to avoid creating a class for each year is to skip one or more years when pointing to the direct parent class if no flow changes have been made within those years that would affect in-flight cases. Instead of always using Param.CurrentYear, the most recent year when class specialization occurred can be determined using a data page using the following logic:

Param.ContractYear = D_ContractYearToUse[ObjClass:Primary.pxObjClass, StartYear:Param.CurrentYear].ContractYear 

.pxObjClass =>.pxObjClass + "-Y" + Param.ContractYear 

The logic within D_ContractYearToUse can be:

.ContractYear = Param.StartYear

For each page in D_StartsWithClassNameDesc[ObjClass:Param.ObjClass].pxResults 

Param.Year = <the last 4 characters in> pyClassName 

IF (Param.Year only contains digits AND Param.Year <= Param.StartYear) 

THEN Primary.ContractYear = Param.Year 

Exit Transform 

Advantage: Classes defined within an application’s ruleset stack are requestor-level information and are compatible with the Case Designer’s ability to display a case’s current state. It does so in conjunction with how the application rule’s Cases & data tab is configured.

Name Work ID prefix Implementation class
BookEvent EVENT- FSG-Booking-Work-BookEvent-Y2022
WeatherPrep WPREP- FSG-Booking-Work-WeatherPrep-Y2021
RoomsRequest ROOMS- FSG-Booking-Work-RoomsRequest-Y2020

Note that application rules configured as shown above would only need to be used during design and development. In production, DCR would be used to establish the pxObjClass that each case type should use.

Drawbacks: A number of arguments can be made against using this approach. Each argument is addressed in the following table.

Argument Counterargument
Creating classes takes extra time It takes very little time to create a new class and configure it to directly extend another class. If you need to create a class only once a year, the amount of time to perform this task is negligible in comparison to other development tasks that would take place within that year.
Inheritance path can become too long and or impact rule resolution performance There is no restriction on the depth of an inheritance hierarchy. Other limits are reached long before inheritance hierarchy becomes an issue.
Extra classes would complicate future database table storage decisions Class groups, work pools, and Data-Admin-DB-Table records determine where data is persisted.
Does not scale Increasing the number of unique pxObjClass values in the same database table does not affect system architecture.

Approach 3: Switch the application version of in flight cases

This approach allows users to process existing assignments without having to update the flows. Add a new access group that points to the previous application version. Then, add the access group to the operator ID to switch to the application from the user portal and complete the existing assignments.

In this example, an application has undergone a major reconfiguration. A new version of the application is created that includes a newer ruleset version. Updates include reconfigured flows and decisioning and data management functionality. It is decided to create a new access group due to the extent of changes beyond flow updates.

This figure shows someone’s Operator record having the ability to access two version of the Booking application, 01.01.01 and 01.01.02. This may be necessary when a requirement exists to complete in-flight cases according to the version in which the application was created. Care must be taken to only display cases and assignments created in the current Application version. GetNextWork could need to avoid pulling work associated to a different version. Batch processing would also need to observe this rule.
Advantage The original and newer versions of the application remain intact because no attempt is made to backport enhancements added to the newer version.
Drawback Desirable fixes and improvements incorporated into the newer application version are not available to the older version.

Care must be taken to avoid processing a case created in the new application version when using the older application version and vice versa. Both cases and assignments possess a pxApplicationVersion property. Security rules, such as Access Deny, can be implemented to prevent access to cases and assignment that do not correspond to the currently used application version.

The user's worklist can either be modified to only display cases that correspond to the currently used application version or the application version can simply display as separate a worklist view column. Likewise, Get Next Work should be modified to only return workbasket assignments that correspond to the currently used application version.

Approach 4: Process existing assignments in parallel with the new flow

 This approach preserves certain shapes, such as Assignment, Wait, Subprocess, and Split-For-Each, within the flow even though newly created cases no longer use those shapes. The newer version of the flow is reconfigured such that new cases never reach the previously used shapes. Yet, existing assignments continue to follow their original path.

In this example, you have redesigned a process so that new cases no longer utilize the Review and Correct assignments. You replace them with Create and Review Purchase Request assignments. Because you only need to remove two assignments, you decide that running the two flow variations in parallel is the best approach.

Assignment parallel

You make the updates in the new flow version in two steps.

First, drag the Review and Correct assignments to one side of the diagram. Remove the connector from the Start shape to the Review assignment. Keep the Confirm Request connector intact. This ensures that in-flight assignments can continue to be processed.

Next, insert the Create and Review Purchase Request assignments at the beginning of the flow. Connect the Review Purchase Request to the Create Purchase Order Smart Shape using the Confirm Request flow action.

Assignment parallel

Later, you can run a report that checks whether the old assignments are still in process. If not, you can remove the outdated shapes in the next version of the flow.

Advantage All cases use the same rule names across multiple versions.
Drawback This approach may not be feasible given configuration changes. In addition, it may result in cluttered Process Modeler diagrams.

Approach 5: Circumstance

This approach involves circumstancing as many rules as needed to differentiate the current state of a flow from its desired future state. One type of circumstancing that satisfies this approach is called as-of-date circumstancing. As-of-date is when a property within a case is identified (for example, pxCreateDateTime). That property is then used as the Start Date within a date range. The End Date within the date range is left blank. An application-specific DateTime property,  such as .CustomerApprovalDate, can be used as well.

Circumstancing rules to handle business logic changes that occur when cases are in-flight is a possibility but not recommended. One drawback is that circumstanced rules are not displayed in APP Studio. Any rule that is launched would be the base rule.
Advantage Simple to implement at first with the App Explorer. No need to switch applications.

The drawbacks to the use of circumstancing are listed in the Designing for specialization module. The primary drawback is that the Case Designer is affected when circumstancing is used except for its support for specialized Case Type rules. Case Type rules cannot be specialized by DateTime property, as-of-date circumstancing is not allowed. This presents a problem in that the changes should be carried forward indefinitely.

Because the Case Designer’s scope is requestor-level, the Case Designer sees only the base versions of circumstanced rules, such as flows. Whenever a circumstanced rule is opened from another rule, the base version is shown. To locate the correct circumstanced variation of the base rule, click Action > View siblings. The greater the number of circumstanced rules, the harder it becomes to visualize how the collection of similarly circumstanced rules and non-circumstanced rules interact.

Circumstance date
In the Settings tab for a case type is a menu named Specialization. Show the screen that appears when the Specialization menu item is clicked. You can also open the case type rule then use Save-As -> Specialize by circumstance.


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?

100% found this content useful

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