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

From AgileApps Support Wiki

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.

Notepad.png

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:

Utl.png

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 GearIcon.png > 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.GearIcon.png > 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:
Aa.png

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 GearIcon.png > 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:
Ab.png

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.
Ac.png

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:
Ad.png

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

Ae.png
8. Click the Check Syntax button to validate the model:
Af.png
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:
Nn.png
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 GearIcon.png> 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:

Nm.png

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):
Oo.png
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.
Op.png
6. Double click the arrow going to the End Event. A dialog appears that lets you set conditions.
Oq.png
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.
Or.png
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:
Os.png
8. Click the Check Syntax button to validate the model:
Af.png
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.

Notepad.png

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.

Notepad.png

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 GearIcon.png> 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 GearIcon.png> 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.
Za.png
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.
  4. Next to All of these Conditions, click [Add Condition]. A field chooser dialog appears.
  5. Select the Due Diligence Checks field, and click [Insert Field]
Zb.png
6. Choose the contains operator, and test for Background Check. The first condition is created.
Zc.png
  • The label you test for must be an exact match of the label specified when the field was defined.
  • 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.
7. Repeat the process for the References Check:
Zd.png
The processes that cause these fields to be set run only for a Phase I case record, so there is no need to add a test to make sure we are in Phase I, as neither of these fields will ever be set in a Phase II record.
8. Click [Save]. You can see the expression that is created for the Rule.

Ze.png

You can write expressions like this one by choosing “When specified expression is true”, rather than “When specified condition is true”. The result is the same, but the procedure you just used is generally easier.
Specify Actions

It is now time to specify the actions the Rule will take when the conditions are satisfied.

1. To resume editing, click the name of the rule you just created (Begin Phase II when ready).
2. Under Actions to Perform, follow the steps below to mark the existing (Phase I) case record as Resolved, and to create a new (phase II) case record that links to it:
A. Select Set Status and mark the current case record Resolved.
Zf.png
  • As with any action that modifies a field, you can choose whether or not to trigger execution of any record-update rules that may have been defined on this object.
  • Here, the choice is not to do so.
B. Click [Add More].
C. Select Add Note and add the text 'Launching Phase 2' (including the single quotes).
Zh.png
  • Both variables and text can be added. (The variable selector is under the field. It works the same as the one you saw when creating an email template.)
  • Text strings must be in quotes.
D. Click [Add More] once again, select Add Record, and choose the Onboardings object.
E. Initialize the Parent Case field:
  • Click in the Field box.
A list of appears, showing the labels of fields in the record you are creating.
  • Choose Parent Case.
  • Click in the Value box. Additional buttons appear.
  • Click [Choose Field].
A list appears showing labels of fields in the current record.
  • Choose Record ID.
The field name (id) is inserted into the action.
When this rule executes, the value on the right is assigned to the field on the left. Here, the Lookup field in the new record gets the record ID from the current case. (That’s what Lookup fields contain as their values.)
F. Click [Map Additional Fields] and repeat the process to set the values for these fields, using the screenshot below as a guide:
Employee Name
The field label is chosen (Employee Name) from the list. When inserted, the actual field name is included (subject). To that, add additional text that says ‘Phase 2’, and add the case number for ease of reference. Click the [Check Syntax] button here, to make sure that everything is correct:
subject + ' - Phase II - ' + case_number
Recruiting Notes
Add a note that refers the HR Rep to the original case record:
See the parent case for the notes.'
'As with all text strings, this one is enclosed in single quotes.
Onboarding Phase – The value from the picklist field: ‘Onboarding’ g)
Click [Map Additional fields] to see what you have so far most clearly:
Zi.png
H. Add these fields to transfer critical data from fields in the old case to the new one:
Zg.png
As you scroll through the list, you see fields with an angle bracket at the end, like this:
Hiring Manager >
Those entries occur for lookup fields. When you click one, another list of fields opens up to the right, showing fields in the target record. The actual value of the lookup field is the one you copied:
Hiring Manager_id
3. When done, click [Save].
The rule is now complete, with the actions to take indicated, as well as the conditions.
Zj.png
Create the Phase I Event Rules

Next, you’ll create event rules to keep track of which Phase 1 processes have completed. After each rule sets the appropriate flag, it will invoke the Rule Set that tests to see whether all flags have been set.

Create the Process Completed rules:
  1. Go to GearIcon.png> Case Automation > Business Rules
  2. In the Events tab, choose On Record: Process Complete
  3. Click [New Rule]
Name – Mark Background Check Done
Process – Background Check
Execution Criteria – Unconditional
Actions to Perform – Update Record,
[Choose Field to Update]
Click the button and select Due Diligence Checks. Then click [Insert Field]
Value: IF( ISNULL(due_diligence_checks), 'Background Check', due_diligence_checks+',Background Check')
For a single checkbox field, the value would simply be true, with no quotes around it. But for a multi checkbox group, we add the label text to the existing value, in case the references check finished first. (If the field is empty, the label is assigned to it. Otherwise, the checkbox label is appended to it.)
4. Under Actions to Perform, click [Add More]
Select Action: Execute Rule Set
Select Rule Set: Begin Phase II when Phase I is complete
[File:Zk.png]]
5. Click [Save].
You see the Process Complete rule list, with the rule added.
6. Click [New Rule]
Name – Mark References Check
Done Process – References Check
Execution Criteria – Unconditional
Actions to Perform – Update Record
[Choose Field to Update]: Due Diligence Checks.
[Insert Field]
Value: IF( ISNULL(due_diligence_checks), 'References Check', due_diligence_checks+',References Check')
7. Under Actions to Perform, click [Add More]
Select Action: Execute Rule Set
Select Rule Set: Begin Phase II when Phase I is complete
8. Click [Save].
Both Rules now appear in the list.
Create the Case Created rules:

These rules launch the appropriate processes when a case record is created.

1. Go to GearIcon.png> Case Automation > Business Rules
2. In the Events tab, chose On Record Created
3. Click [New Rule]
Name – Launch Phase I Processes
Execution Criteria – When specified conditions are true
All of these conditions: [Add Condition]
Select Field: Onboarding Phase
Select Operator: is one of
Select Value: Pre-Boarding
Actions to Perform -
Action - Change Process Status
Process – Onboarding Prep
Status – Disable
(To ensure that the Phase 2 process isn’t started for this case record.)
[Add More]
Action - Start Process
Process – Background Check
[Add More]
Action - Start Process
Process – References Check
4. Click [Save]. The rule appears.
Zl.png
5. Click [New Rule]
Name – Launch Phase 2 Process
Execution Criteria – When specified conditions are true
All of these conditions: [Add Condition]
Select Field: Onboarding Phase
Select Operator: is one of
Select Value: Onboarding
Actions to Perform
Action - Change Process Status
Process – Background Check
Status – Disable
(To ensure that the Phase 1 process isn’t started for this case record.)
[Add More]
Action - Change Process Status
Process – References Check
Status – Disable
[Add More]
Action - Start Process
Process – Onboarding Prep
6. Click [Save].
The Phase 2 rule appears after the Phase 1 rule.
(The order in which rules execute can be modified, but it makes no difference here.)
Zm.png

Test the Application

You are now ready to test the application:

1. Create a new case.
2. Complete Phase I Processes.
Note that the Phase II case record is created.
3. Complete the Phase II processes. Note that the case is closed.

Notepad.png

Note: When the final pre-boarding process is completed, and the second record is created, you are still viewing the original record! The onboarding process was started in the second record, so the record you’re on seems “incomplete”. (It has been marked as Resolved, but that may not be immediately obvious as you examine the screen.) What’s needed is a function extends a robotic arm out of the screen, grabs the mouse, and positions the agent at the new record. In the meantime, we just have to train them to go back to the case list after completing a process!