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

From AgileApps Support Wiki
Revision as of 12:07, 7 March 2023 by Wikieditor (talk | contribs) (→‎Create a Rule Set to Launch Phase II)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Overview

This article 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 the article and other useful pages can be found in the support wiki’s 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 and 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 is something the AgileApps case management platform was not originally designed to do. (It may do well 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 is 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 cannot 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 representative 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

You must 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 many other field types that are available. (Note that adding fields here gives you many more field type choices than you had in the Wizard.)

  1. Go to Configuration GearIcon.png > Case Management > Case Fields.
  2. Click New Field to create new fields. After you enter the details, click Save and New.
    (These values will be displayed as read-only. They are to be modified by the new processes. Refer to the following table to create new fields.)
  3. When done adding the last field, click Save.

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.

Customize the Form

  1. Go to Configuration GearIcon.png > Case Management > Case Forms.
  2. Click the Default Layout form.
  3. 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.
  4. 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 will set up two independent processes that will run as “parallel tracks” for a new employee. When both processes end, you will use events and rules to start the Phase II process. Later, you must add 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 sequence of manual and automated tasks, potentially with conditional branching and other sophisticated features. This is 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 enter the task information:

    Ab.png

    Here, you are telling the owner of the current case (the HR representative) 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 it is done, the Agent marks it as Complete. (You will see how that works in a moment.)
  5. Click Save.
  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 will 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 representative (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 representative:
    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 use parentheses and you can add additional conditions by clicking the + icon. 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 arrow to indicate the conditions under which it is taken.

    Or.png

    Use the same procedure on the arrow 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 must 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 will 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. 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 will 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 Configuration 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:
    1. 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 the execution of any record-update rules that may have been defined on this object.
      • Here, the choice is not to do so.
    2. Click Add More.
    3. 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.
    4. Click Add More once again, select Add Record, and choose the Onboardings object.
    5. 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.)
    6. 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’
      Click Map Additional fields to see what you have so far most clearly:

      Zi.png

    7. 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
    8. 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

You must 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 Configuration > 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. 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.

    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 Configuration > Case Automation > Business Rules.
  2. In the Events tab, choose 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!

Previous Article

Next Article


Back to Article Index