Handling flow changes for cases in flight

To complete the solution, you will do the following:

1. Create Event Booking test cases.
2. Create the new Executive Officer Operator IDs.
3. Create a new Booking patch ruleset version.
4. Update the FSG organization record.
5. Modify the ExecutiveReview_Flow process.
6. Create the maintenance activity.
7. Create a new DevMaintenance ruleset.
8. Create a new ShouldRestartCase when rule.
9. Create a new RestartStageFromWorklist activity.

Prior to developing the solution, create test cases with 3000, 6000, and 11,000 attendees and advance them to the executive approval stage.

Create a new Executive Officer operator ID that uses the default workgroup. Create two more new Executive Officer operator IDs that uses a new Executives@FSG work group.

1. In your exercise system, log in as Admin@Booking.
2. Create a new Executives@FSG work group and set the Manager IDs to CEO@Booking and Admin@Booking.  Also associate the new Executives@FSG work group with a new Booking:ExecutiveOfficers work queue.
3. Open the existing CEO@Booking operator ID and set its default work group to Executives@FSG
4. Copy the existing existing CEO@Booking  operator ID using the following settings.  

   Field	Setting
   Short description	Executive Officer 1
   Operator ID	ExecutiveOfficer1@Booking

5. Click Create and open to create the operator ID.
6. In the Profile tab, change the Full Name to Executive Officer 1 and the Email to [email protected].
7. In the Work tab, change the default Work group  to default@FSG only for Executive Officer 1.
8. Save the new ExecutiveOfficer1@Booking operator ID.
9. Repeat the step 4-8 for ExecutiveOffice2 and ExecutiveOfficer3.

To facilitate testing, create a new patch ruleset version for the Booking ruleset. This allows you to create cases using the original configuration and then test the changes by including or excluding the patched ruleset version in the application definition.

Update the Booking application definition to ensure that you have access to the new Booking patch ruleset version.

To facilitate routing to the CEO@Booking, update the FSG organization record so that CEO@Booking is the Controller operator ID.

1. Open the FSG organization record.
2. Set the CFO/Controller Operator ID field to CEO@Booking.
3. Save the updated organization record.

Introduce the change using new shapes in the ExecutiveReview_Flow flow and add a decision mechanism to route events with fewer than 5,000 attendees to the first executive officer, to route events with attendees between 5,000 and 10,000 to the second or third executive officer, and to route events with more than 10,000 attendees to the CEO.

1. In the App Explorer, open the (FSG-Booking-Work-Event) ExecutiveReview_Flow process.

2. Save a copy of the flow to the new Booking patch ruleset version.

   Caution: Do not remove the existing Approve Event Quote smart shape. Doing so orphans any existing approval assignments.
3. Add a decision shape labeled Approved By?, configured as a Fork type.
4. Create an IsCEOApprovalRequired when rule. Define the When condition as <var>Number of Attendees</var> > 10000. Link it to the existing Approve Event Quote smart shape and rename it to CEO Approval. Change the likelihood to 20.
5. Create an IsFirstExecutiveApproval when rule. Define the When condition as Number of Attendees <= 5000.
6. Create an IsFirstExecutiveApproval when rule. Define the When condition as Number of Attendees > 5000 and <=10000.
7. In the First  Executive Review Approval smart shape, configure routing to the ExecutiveOfficer1@Booking operator. Change the likelihood to 50.
8. In the Second  Executive Review Approval smart shape, configure routing to the Executives@FSG workqueues.Change the likelihood to 30.

9. In both Approval Smart Shape ,if Rejected  Change stage to Approval Rejection in the Stage field as below.

   

   The reworked ExecutiveReview_Flow process is shown in the following diagram.

   

Additionally, an activity identifying any cases in flight positioned at the Executive Review step in the flow is required. The activity restarts the flow for those cases so that they get routed according to the new logic.

To create the new RestartStageFromWorklist activity, do the following.

1. Create a new DevMaintenance production ruleset that is accessible by only the Admin@Booking operator ID.
2. Create a new ShouldRestartCase when rule for the RestartStageFromWorklist activity to use.
3. Create a new RestartStageFromWorklist activity that restarts the stage for a parameterized operator..

Create a new DevMaintenance ruleset

As a best practice, place this type of maintenance activity in it's own ruleset that is accessible only by developers and administrators.

1. Using the Records Explorer, find and open the Booking:Administrators access group.
2. In the Advanced tab of the Booking:Administrators access group, enter DevMaintenance in the Production Ruleset list.
3. Click the target icon to create and open the record.
4. Save the new ruleset. Then save the updated Booking:Administrators access group.
5. Log out and log back on as Admin@Booking.

Create a new ShouldRestartCase when rule

Initially configure the ShouldRestartCase when rule to always return true.

1. Create a new ShouldRestartCase when rule. Use the following settings.

   Field	Setting
   Label	Should Restart Case
   Development branch	No branch
   Production Rulesets	Select radio button
   Apply to	Assign-Worklist
   Add to ruleset	DevMaintenance

2. Click Save and Open to create the ShouldRestartCase when rule.
3. In the Conditions tab, specify a when condition Rule Always evaluates to true.
4. If necessary, you can use a specific case type Apply to class to override the ShouldRestartStage when rule.

Create a new RestartStageFromWorklist activity

This activity restarts the stage for the case and repositions the flow. The activity only acts on cases in the parameterized operator id. If a large number of cases require updating, configure the activity so that it has robust error handling and periodic commit capabilities.

1. Create a new RestartStageFromWorklist activity. Use the following settings.
    

   Field	Setting
   Label	Restart Stage From Worklist
   Development branch	No branch
   Production Rulesets	Select radio button
   Apply to	Work-
   Add to ruleset	DevMaintenance

2. Click Save and Open to create the new RestartStageFromWorklist activity.
3. In the Parameters tab, enter two parameters as defined in the following tables.

   Operator parameter

   Field	Setting
   Name	Operator
   Required	Yes
   Data type	String
   In/Out	In

   RefObjectKey parameter

   Field	Setting
   Name	RefObjectKey
   Required	No
   Data type	String
   In/Out	Out

4. In the Pages & Classes tab, declare the following:

   Page name	Class
   D_Worklist.pxResults	Assign-Worklist
   CasePage	Work-

   The completed tab looks like the following image.

   
5. In the Steps tab, add the following steps.
    

   Step	Method	Step page	Description
   1	Property-Set	D_Worklist[OperatorID:param.Operator] .pxResults	Loop D_Worklist[OperatorID:param.Operator] .pxResults when ShouldRestartCase
   1.1	Obj-Open-By-Handle	CasePage	Open by Param.RefObjectKey handle set in loop, lock, release on commit
   1.2	call pxRestartStage	CasePage	Restart the Stage that the case is in
   1.3	Obj-Save	CasePage	Save
   1.4	call commitWithErrorHandling	CasePage	Commit with error handling
   2	Page-Remove	Page-Remove	CasePage

6. For Step 1 in the activity, do the following:
   1. Configure Loop to Repeat For each embedded page.
   2. In the When section, do the following:
      1. Select the Enable conditions before this action check box.
      2. In the When field enter the new ShouldRestartCase when rule. In the if true field, select Continue Whens. In the if false field, select Exit Iteration.

      The completed When section looks like the following image.

      
   3. For the Property-Set method, configure the Method Parameters to set PropertiesName Param.RefObjectKey to PropertiesValue .pxRefObjectKey.

      The completed Method Parameters section looks like the following image.

      
7. For the Obj-Open-By-Handle method in Step 1.1, set the InstanceHandle value to Param.RefObjectKey as shown in the following image.
   

   The completed Steps tab is shown in the following image.

   
   Note:
   In current scenarios existing work objects are in Worklist , so activity is  based on Worklist . To handle work object from  workbasket , Assignment class should be changed to Assign-Workbasket and Data page referred to be D_Workbasket.

Test the changes by running the RestartStageFromWorklist activity as follows:

1. Open the RestartStageFromWorklist activity and select Actions > Run.
2. Use CEO@Booking as the Operator parameter and select Run. If the maintenance activity runs correctly, a confirmation dialog with a green check mark is displayed.
3. Reopen the cases you created earlier to verify that they are assigned to the correct operators or workbasket based on the updated flow.

Consider using a Cascading Approval Flow Type instead of a Single Approval Flow type.  With a Cascading Approval Type you could establish approval based on an authority matrix that uses a Decision Table for the matrix.  The decision table would use the number of attendees to determine where to route the case.  This will still require running an activity in production to restart the stage for those cases pending executive approval, but it would greatly simplify the flow.  Would this approach work?  Why or why not?  What if you wanted to use the Booking:ExecutiveOfficers work queue in combination with Operator work lists?

Several approaches to working with cases in flight during code releases are available. However, letting only a subset of operators deal with the current cases is not a viable solution because the affected cases require repositioning shortly after the code release.

This solution leverages the fact that the executive review is the first step in the stage. If the executive review is not the first stage, a ticket needs to identify the point to jump to in the flow. A ticket can be used here as well, but it becomes a leftover artifact after the change has been implemented.