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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.