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

Managing flow changes for cases in flight

There are several fundamental approaches to safely updating flows that are already in production. Because each application configuration and 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: Switching 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 so that the operator can switch to the application from the user portal.

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


Advantage: The original and newer versions of the application remain intact since 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 not to process 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 2: Processing existing assignments in parallel with the new flow

This approach preserves certain shapes, such as Assignment, Wait, Subprocess, Split-For-Each, and so on, within the flow despite those shapes no longer being used by newly created cases. 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 will 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.

Second, 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.

Drawbacks: This approach may not be feasible given configuration changes. In addition, it may result in cluttered Process Modeler diagrams.

Approach 3: Circumstancing

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 would satisfy 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 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 could be used as well such as a property such as .CustomerApprovalDate.


Advantage: Simple to implement using the App Explorer. No need to switch applications.

Drawbacks: The drawbacks to the use of circumstancing were 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 may need to be carried forward indefinitely.

Circumstance date

Since the Case Designer’s scope is requestor-level the Case Designer only “sees” the base versions of circumstanced rules such as Flows. Whenever a circumstanced rule is opened from another rule, what is shown is the base version. To locate the correct circumstanced variation of the base rule, the “Action > View siblings” menu option must be used. The greater the number of circumstanced rules, the harder it becomes to “picture” how the collection of similarly circumstanced rules, and non-circumstanced rules interact.

Approach 4: Moving 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.

Advantage: 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 and makes upgrades easier. The activity also facilitates flow configuration and maintenance in APP Studio.

Drawback: 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 5: Using direct inheritance and dynamic class referencing (DCR)

This approach is a hybrid solution that involves circumstancing for shared work pool-level rules and direct inheritance for case-specific rules. For case-specific rules, differentiation of a flow’s current state from its desired future state is accomplished using direct inheritance and DCR. The example below illustrates this approach.

Work pool-level As-of-Date Circumstancing Case-specific Direct Inheritance

FSG-Booking-Work HypotheticalSharedSubFlow

FSG-Booking-Work-BookEvent-Y2020 Find by name first (Pattern) = false Parent class (Directed) = FSG-Booking-Work-BookEvent

In combination with the differentiation value being set, the pxObjClass of the case would be changed. In the example above, the value of the differentiating property, pxCreateDateTime is established immediately upon case creation. 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 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 could 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 could 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 so 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 addresses below.

Argument Counter Argument
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 only need to create a class 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 would be reached long before inheritance hierarchy would become an issue.
Lengthy inheritance path would impact rule resolution performance Rule resolution begins with a database query. Circumstanced rules are evaluated at the end of the 10-step rule resolution algorithm. Class names are examined at the beginning. An extra row in the database is an extra row whether due to having a different pxObjClass value or different pyCircumstanceProp and pyCircumstanceVal column values.

Rule resolution is only performed so many times before the resolved rule is cached. The rule cache is based on usage patterns. Over time the rule cache will evolve whether as-of-date circumstancing or date-based direct inheritance is used.
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.

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