Managing flow changes for Cases in flight

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.

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.

• Advantage: One 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 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.

Disadvantage: Desirable fixes and improvements incorporated into the newer application version are unavailable to the earlier version.

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:

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.

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.

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.

Advantage

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

Disadvantages

• 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: