Managing flow changes for Cases in flight

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:

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

Example

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.

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.

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.

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.

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.

 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.

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.

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.

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.