Skip to main content

Managing flow changes for Cases in flight

In the ever-changing IT industry landscape, change is not only a constant but also an essential component of progress. As technology advances and business requirements evolve, adaptability is key to ensuring our continued success.

It is imperative to approach change with a mindset of readiness and resilience. Embracing change allows us to stay at the forefront of innovation, respond effectively to shifting demands, and remain competitive in an ever-evolving industry.

The design of Pega Platform™ applications is flexible enough to accommodate changes, whether you extend the existing application or specialize a flow for specific needs. Several fundamental approaches exist to safely update flows already in production in your Pega Platform application. Because each application configuration and business setting is unique, choosing the approach that best fits your situation is critical.

Consider the following approaches to manage flow changes:

  • Move existing Assignments using a ticket
  • Switch application version
  • Parallel processing
  • As-of-date circumstance
Caution: Whichever approach you choose, always test the Assignments with existing Cases, not just the newly created Cases.

Move existing Assignments by using a ticket

To understand the process of reassigning tasks by using tickets, consider a scenario where a Case moves from the Review Loan Request Step to the Confirm Request Step and then to the Fulfill Request Step.

After an update, assume that the Confirm Request Step is no longer in the application. As a result, you have ongoing Cases in the Confirm Request Step that the system suspends without a clear path forward. To solve this flow issue, you can use a ticket.

You can create a ticket, and then associate it with the Fulfill Request Step. Next, the system can identify all pending Assignments, and users can open and lock the instance. The following figure shows the updated flow and the ticket associated with the Fulfill Request Step. A snapshot of the activity that uses SetTicket is also displayed.


After you configure the activity, deploy the updated flow and run the bulk Assignment activity. The call to the Set Ticket utility causes the system to raise or activate the specified, which immediately influences the processing of any flow (of the appropriate Work- class) that contains a ticket of that name.

As a best practice to streamline your application, invoke the standard Work-.SetTicket activity from your activity rather than referencing the Obj-Set-Tickets method. The Work-.SetTicket activity sets and subsequently resets a single ticket, which is identified in an activity parameter.

Note: The system must be offline when you run the activity.

For 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.

  • AdvantageOne time utility to solve the problem flow issue for inflight Cases after flow update.
  • Disadvantage: 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.

Switch the application version of in-flight Cases

Switch the application version of in-flight Cases so that users can process existing assignments without updating the flows. Add a new access group that points to the previous application version. Then, add the access group to the operator ID record to switch to the application from the user portal and complete the existing assignments.

For example, an application undergoes a significant reconfiguration. A new version of the application includes a more recent Ruleset version. Updates include reconfigured flows and decisioning and data management functionality. The development team decides to create a new access group because of the extent of changes beyond flow updates.

In the following figure, the operator record of a user grants access to two versions of a Booking application, 01.01.01 and 01.01.02. This setup might be necessary when there's a need to complete in-flight Cases according to the version in which Case creation happened. The design should only show Cases and assignments created in the current application version. getNextWork might need to bypass pulling work associated with a different version. Batch processing should also follow this Rule.


Avoid processing a Case created in the new application version when using the earlier application version and vice versa. Both Cases and Assignments have a pxApplicationVersion property. You can implement security Rules such as Access Deny to prevent access to Cases and Assignments that do not match the currently used application version. You can adjust the worklist to display only Cases that match the currently used application version, or you can display the application version as a separate worklist View column. Similarly, adjust getNextWork to return workbasket assignments that match the currently used application version.

Advantage: The original and newer versions of the application remain intact because no attempt is made to backport enhancements that are in the more recent version.

DisadvantageDesirable fixes and improvements incorporated into the newer application version are unavailable to the earlier version.

Parallel processing

In this approach, you have a flow process existing Assignments in parallel with the new flow to preserve certain shapes, such as Assignment, Wait, Subprocess, and Split-For-Each, within the flow even though newly created Cases no longer use those shapes. You can reconfigure the newer version of the flow so that new Cases never reach the previously used shapes. Existing Assignments continue to follow their original path.

For example, you redesign a process so that new Cases no longer use 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, as shown in the following figure:

Two variations of the flow run in 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 method ensures that in-flight Assignments can continue for processing.

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 by using the Confirm Request flow action.

The following figure shows the resulting flow:


Later, you can run a report that checks whether the earlier 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.

Disadvantage: This approach might not be feasible if there are configuration changes. In addition, it might result in cluttered Process Modeler diagrams.

As-of-date circumstance

Circumstance as many Rules as necessary 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 the system identifies a property in a Case(for example, pxCreateDateTime), and that property then becomes the Start Date in a date range. The End Date in the date range remains blank. You can also use an application-specific DateTime property, such as .CustomerApprovalDate.

Event Manager Assignment.

You can circumstance Rules to handle changes in business logic that occur when Cases are in-flight, but this method is not a best practice. One drawback is that circumstanced Rules are not displayed in App Studio. When configuring the Rules in App Studio, only the base version of the Rule is visible even though it has a circumstanced version of the Rule available.


  • Simple to implement at first with the App Explorer. No need to switch applications.


  • The primary drawback of circumstance is that the Case Life Cycle in Dev Studio or App Studio does not reflect the circumstance Rules, except for its support for specialized Case Type Rules. You cannot specialize Case Type Rules by using the DateTime property because the system does not allow as-of-date circumstancing.
  • Because the Case Life Cycle in Dev Studio or App Studio works in the scope of requestor, you can see only the base versions of circumstance Rules, such as flows. The base version is displayed whenever a user opens a circumstanced Rule from another Rule. 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.

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