Building an Advanced Two-Phase Case Management System in the AgileApps Cloud

Overview

This paper describes an advanced implementation of an Employee Onboarding application that creates a second case record and launches the attendant processes when the processes attached to the first record have been completed. It represents a deeper dive into the platform that demonstrates some of the things you can do with advanced rules and processes.

Note: If you haven’t already read it, this article describes the basic application: Building a Dynamic Case Management Application in the AgileApps Cloud Links to those articles and other useful pages can be found in the support wiki’s Article Index at Article Index

The Goal: Set Up a Two-Phase Onboarding Process

The goal of the implementation is to create a process suitable for onboarding new employees, in two phases.

Requirements & Strategy

• Manage the process in two phases, each with its own deadlines.
  • In the first phase, the organization has a week to prepare for the new employee
  • In the second phase, the organization has a day to get the person into their new position
• Notifications should be sent if either of the two phases reaches 90% of its time limit.

Meeting the Challenge of Two-Phase Onboarding

The need for a two-phase approach represents a major challenge for this case study. That’s something the AgileApps case management platform was not originally designed to do. (It may well do so in the future, however, in response to needs like this one.) The strategy for meeting that challenge is to create two records for each case, and to use a combination of event-handing and rules to begin the second phase automatically when the first is done:

Here’s how it works:

1. When a new case is created, a Case Created event occurs.

The Rules associated with that event check to see which kind of case it is: Phase I or Phase II.

For a Phase I case, processes associated with Phase II are disabled, so they can’t be launched inadvertently, and Phase I processes are initiated. For a Phase 2 case, the reverse is true.

2. Track process completion.

When a process completed event occurs, run rules to determine which process it is, and set the appropriate flag in the case record to record the fact that it has been done.

3. Determine when the next phase can begin.

When all processes in Phase I have been completed, Phase II can begin.

4. If all of the flags are set, mark the current case as Resolved.

It could also be marked as Closed, which is almost the same thing, but when an HR Rep sees the Resolved status in their list of cases, they immediately know that Phase II is in progress.

5. Create the child case record for Phase II.

The new record points back to the original one, so the two remain tied together.

A flag is set to further indicate that this is a Phase II record.

6. Launch Phase II Processes.

Another flag in the record identifies it as a Phase II case, triggering the Case Created rule that disables processes for Phase I and enables those for Phase II.

7. Close the case.

When all onboarding preparations are complete, the case can be closed.

Mapping the Requirements to Platform Capabilities

The following table shows the functional capabilities used to implement the new system requirements.

Requirement	Functionality
Start Phase II only when Phase I is complete	Use Rules triggered by Case Events to create records and initiate the appropriate processes.

Customize the Application

Start by opening the Employee Onboarding application created in the companion article: Building a Dynamic Case Management Application in the AgileApps Cloud

Add Additional Case Fields

Next you’ll add some additional fields that the Cases object needs. The need for them will become more apparent when the Business Processes are created. For now, as you go through the process just note the different kinds of fields, and take a moment to examine the many other field types that are available. (Note, too, that adding fields here gives you many more field type choices than you had in the Wizard.)

1. Go to > Case Management > Case Fields
2. Click [New Field] to specify needed fields. As each is defined, click [Save & New].

(These values will be displayed as read-only. They are to be modified by the new processes.)

Field Label	Display Type	Notes
Onboarding Phase	Picklist	Values: Pre-Boarding, Onboarding. (Will equate to 1 and 2, respectively.) Default : 'Pre-Boarding' (include the single quotes)
Parent Case	Lookup	Object Name: Onboardings Lookup Field Configuration: Default (none). This field will be set by the system to connect the Phase 2 case record to the Phase 1 record.

3.When done adding the last field, click [Save].

Customize the Form

Go to

4. > Case Management > Case Forms.

5. Click the Default Layout form.

6. Change the properties of Onboarding Phase and Parent Case, to Read Only, as they will be modified programmatically:

• Click the Edit Field icon
• For Field Attributes, select Read Only.
• Click [Save].

7. Click and drag on the Move-arrows icons to change the position of the fields to create an arrangement like the one shown here:

Automating the Procedures

Here, you’ll set up two independent processes that will run as “parallel tracks” for a new employee. When both processes end, you’ll use events and rules to start the Phase II process. Later, you’ll ad d rules that use the case fields you added to track the process completions.

Define the First Phase I Process

Every active process in the system has a record associated with it. That record tracks the progress of the process for a given case. A Process is a template for those records. Underlying the template is a shared Process Model that defines the sequences of manual and automated tasks, potentially with conditional branching and other sophisticated features. This a simple two-step process, so the goal here is mostly to see how a process is constructed. Create the Process:

1. Go to > Case Automation > Processes

2. Click [New Process]

3. Drag in a Start Event.

4. Drag in a User Task and fill in the task information:

Here, we’re telling the owner of the current case (the HR Rep) to get the background-information form filled out, and to deliver it to the security agency for verification. When this part of the process is reached, a task appears for the case in the Agent’s sidebar. When done, the Agent marks it as Complete. (You’ll see how that works in a moment.)

5. Click [Save].

Advanced Two-Phase Case System AgileApps Cloud 29 May 2015, pg 7

6. Create another User Task to get the results from the security agency.

Here, we have simply left the Form and Change Status fields empty, rather than choosing “None”. The effect is the same. (Were the background check to fail, we’ll assume the agent adds a note to the case and changes its status. But we’ll focus on the “happy path” here, and assume that everything succeeds.)

7. Align the tasks, and draw the arrows between them. Then click the second task, and select the End Event icon:

The end-event is added to the diagram, and an arrow is drawn to it:

8. Click the Check Syntax button to validate the model:

9. Finally, press Ctrl+S or click the disk icon in the upper left to save the process model. The Save dialog appears.

10. In the Save dialog, specify the Process Name: Background Check.

11. Click [Save]. The process page appears:

Create the Second Phase I Process

Here, you’ll create a process that asks the hiring manager to check references. This one includes an Approval Step to record the results. Create the Process:

1. Go to > Case Automation > Processes
2. Click [New Process]. The Process Model editor opens.
3. Drag in a Start event, as before. Then drag in an Approval Step. A dialog box opens for that step:

When this step is reached in the process, a task appears for the Hiring Manager that has two buttons: [Approve] and [Reject].

A comment is required this time, to encourage the manager to summarize the conversations.

4. If the reference check fails, we want to generate a task for the HR Rep (case owner) to revoke the offer of employment. At that point, the HR rep will close the case. To do that, drag the User Task icon into the diagram, creating an arrangement something like this (for reasons that will be become clear in a moment):

5. When the User Task dialog appears, provide the instructions for the HR Rep:

Step Title: Revoke Offer

Instructions: Revoke the offer of employment.

References were absent or not as good as claimed.

Due Date: 8 hours Assigned To: Individual Owner

To test which button the Hiring Manager clicked, drag a Decision Switch icon into position, draw one arrow to the Revoke Offer task, and add an End Event coming from the other side of the decision switch, and one from the Revoke Offer task.

6. Double click the arrow going to the End Event. A dialog appears that lets you set conditions.

In general, any field in the record can be used. But since the last step was an Approval Step, the top field in the list is Approved, which has Yes and No values. Choose that field, with the value

Yes. (So the process ends when the prospective employee’s references are good.)

Note that you can parentheses, and that you can add additional conditions by clicking the + icon. When you do, you can add AND/OR operators. Combined with the parentheses, those operators let you build up compound conditions of arbitrary complexity.

7. Click [Save].

A label now appears on the arc to indicate the conditions under which it is taken.

Use the same procedure on the arc going to the Revoke Offer task, but set the label to Rejected and select the value No. The process now looks like this:

8. Click the Check Syntax button to validate the model:

9. Press Ctrl+S or click the disk icon in the upper left to save the process model.

10. Give the model a name: References Check

11. Click [Save]

Use Rules and Events to Transition between Phases

All the pieces we need are now in place to do the rules and events processing we discussed earlier, when we talked about Meeting the Challenge of Two-Phase Onboarding.

Note: It is also possible to sequence processes, using event Rules. A rule that is triggered when one process ends can start a new process, effectively sequencing the processes. Since each Rule can carry out multiple actions, the end of one process could trigger the start of many others. We’re not using that capability in this particular application, but it is worth noting that it exists.

For the purposes of this application, there are several events that need to be handled:

• When a case is created, start the appropriate processes

For Phase I, launch the 2 pre-boarding processes and disable the onboarding prep process. For Phase II, launch the Onboarding Prep process, and disable the pre -boarding processes.

• When a Phase I process ends, set the appropriate flag

Keep track of which processes have already been completed.

• When both flags have been set, launch Phase II

In addition to starting the Phase II process, this step initiates the Phase II Service Level Agreement, which sets up important deadlines for the onboarding preparation, with reminder messages and escalation procedures. That part of the system is discussed in the next section.)

In each situation, you’ll use Rules to test for the right set of conditions, and take the indicated actions.

Note: In addition to the rules you will be building, it is worth noting that several additional rules are pre-built into the ServiceDesk system. Those rules are used to send messages when a case has been reopened, or when a significant amount of time (36 hours) has elapsed after a case has been created or been put into the Pending state. (We won’t discuss them any further, at this point. You’ll find them under > Case Automation > Business Rules, if you explore a little.)

Create a Rule Set to Launch Phase II

Each time a Phase I process completes, a rule will cause a flag to be set. When all of the flags are set, the application needs to launch Phase II (by creating a new case record). Each process-completed rule will set its own flag, of course. But after that, all of the process-completed rules need to do the same thing: Test the flags and create the second case record if all of them are set.
Right now, there are only two processes. But there could easily be more. It doesn’t make sense to duplicate the flag-testing and record-creation in each rule, so we’ll use a Rule Set—a collection of one or more rules that can be triggered either by a process step or by another rule. (In this case, the rule set will be triggered by the process-completed rules.)
Create the Rule Set

1. Go to > Case Automation > Business Rules
2. Click the Rule Sets tab
3. Click [New Rule Set]

Name: Begin Phase II when Phase I is complete

Description: If all Phase I processes are finished, create the Phase II record and fill in the important fields.

4. Click [Save].

The Rule Set summary is shown. You can now add one or more Rules to it.

Add a Rule

1. Click [New Rule]
2. Under Basic Information, set Name: Begin Phase II when ready
3. Under Execution Criteria, for Run this Rule choose: When specified conditions are true.

Buttons appear to let you add conditions.

1. Next to All of these Conditions, click [Add Condition].

A field chooser dialog appears.

1. Select the Due Diligence Checks field, and click [Insert Field]

6. Choose the contains operator, and test for Background Check. The first condition is created.

• The label you test for must be an exact match of the label specified when the field was defined.

7. Repeat the process for the References Check:

• For a single checkbox field, the operator would be equals, and the choices would be Yes or No. This checkbox is in a multi checkbox group, so we test for the label.
• We choose “contains”, because the field will eventually contain a comma-separated list of checkbox labels.