Building a Dynamic Case Management Application in the AgileApps Cloud

Overview

This paper shows you how to build an Employee Onboarding application--just one example of many kinds of Dynamic Case Management applications (or DCM Apps, for short) that can be built on the AgileApps platform.

Note: If you haven’t already read them, these articles provide important background information: Introduction to Dynamic Case Management and the AgileApps Cloud™ Choosing a Development Approach in the AgileApps Cloud™

Links to those articles and other useful pages can be found in the support wiki’s Article Index

The Goal: Manage the Onboarding Process

The goal of the implementation is to create a process suitable for onboarding new employees, to make sure that everything that needs to happen is carried out, and that it happens in timely fashion.

Requirements Summary & Overall Strategy

This section summarizes the requirements that were given for the system. (You’ll see more of the details as you read through the article. Here, the idea is to give you an overview.)

Note: Similar requirements exist for a system that could be used to manage voluntary terminations of employment, termination for cause, and/or reductions in force. It’s pretty much the same set of processes, backwards.

The mandatory system requirements were these:

• Define the tasks that need to be performed, and capture the information needed to carry out the process at each stage.
• Kickoff the process and track its progress.

The optional, additional requirements were these:

• Capability to diverge from the set processes. For example, for a high level executive who is transitioning from the Board of Directors, the onboarding process might be handled differently.
• Extend the base template to cover specific onboarding needs. For example, when bringing on Sales personnel, enrollment in the financial system responsible for commission payouts would be an extra process step. Similarly, some positions might include a company credit card or car.
• Notifications should be sent if the onboarding procedure reaches 90% of its time limit.

Prospects for a successful implementation looked good right from the outset, because most of the requirements mapped directly into the capabilities of the AgileApps case management platform— including all of the optional requirements:

• Use business process models to manage the tasks that need to be performed.
• Each step in the model creates a task for the person or collection of people who can carry it out. The system then records which tasks are completed, by whom, and when. The model, meanwhile, allows task steps to occur in sequence, in parallel, or to take a conditional branch that depends on the nature of the case (defined by data stored in the Case record, or other records connected to it).
• Each case has a status that indicates whether it is new, open, closed, or in some intermediate state. The status of each process associated with a case is tracked, as well — making it easy to determine how many cases are open and where they are. Since times are tracked, it is also possible to construct reports to provide insights into case closure rates over time and by person.
• Use the capacity to define Service Level Objectives and Escalation policies (for example to send an email or reassign a case) to make sure that things happen in a timely manner.
• Use Email Templates and Document Templates to created messages and printed documents, each filled in with the appropriate case-specific data.
• For exceptional conditions (like when a board member becomes an executive), the platform allows both single-step and multi-step tasks to be created on the fly by the person handling the case. (A single step task is simply a request for something that needs to be done, assigned to the person or collection of people who can do it. A multi -step task is in reality a mini process, complete with approval-step branching that can be defined and then executed dynamically.)
• The capacity for Case Types, meanwhile, allows for variations on a theme. The default functionality of the main Cases object, along with any customization or extensions to it are shared by each subtype, using an object-oriented construct known as inheritance.

For the basic requirements, then, success was assured. The only thing left is the implementation!

Using Processes and Events

The following diagram shows how processes and events are used to track the tasks that need to be performed to bring someone on board: Here’s how it works:
1. When a new case is created, a Case Created event occurs.

The Rules associated with that event launch the associated processes.

Each process carries out one or more automated tasks, and assigns one or more manual tasks to users, all in the sequence(s) defined by the processes.

2. Track process completion.

When the last task in a process is completed, a process completed event occurs. Additional rules carry out the appropriate actions.

3. Close the case.

In this case, all on-boarding preparations are complete, so the case is closed.

Making the System Comprehensible to its Users

It’s all well and good to know that the onboarding process is really an instance of Case Management, but forcing people to use the terminology of Case Management doesn’t help them to understand that a new, automated system is simply a better way of doing what they already do.

For example, HR doesn’t think in terms of managing “cases”. Rather, HR personnel think in terms of assisting people. Two simple customizations help to make the system more readily comprehensible to its users:

• Change the label of the Cases object

Depending on the nature of the system, it might be called Incidents, Investigations, Requests, or Onboarding Cases. Here, we’ll keep it short and call it Onboardings.

• Change the label of the Subject field

In Case Management, each case has a subject line. That field summarizes the information in the case description, and identifies the cases in a list. Simply changing the label of the field from “Subject” to “Employee Name” makes things easier for the folks in HR.

• Change the name of the Application

Like the label displayed for the main Cases object, the name of the application can be changed whenever it makes sense—something that holds true for applications you install, as well as applications you build.

Summary: Mapping the Requirements to Platform Capabilities

The following table summarizes the system requirements and shows the functional capabilities used to implement them.

Requirement	Functional Capability
Use terminology that is familiar to the application’s users.	Change label of Cases object to Onboardings Change label of subject field to Employee Name
Record the source of the new hire.	Change label of description field to Recruitment Notes
Track process completion, and record the information needed for each step.	Add additional fields to the Cases object
Identify the people responsible for individual tasks	Add Teams and Roles to the application
Make sure that every task which needs to be done is carried out.	Set up Process Models for each phase of the onboarding process. In those processes, create tasks and approval steps, assigned to the people (users, roles, teams) who need to carry them out.
Make sure that onboarding tasks are carried out in time to get the new employee oriented and productive as rapidly as possible.	Set up Service Level Objectives that specify the time in which the onboarding tasks must occur.
Accommodate compressed onboarding timelines of a few days, and extended timelines of several weeks, as well as a standard one-week timeline.	Use Case priority levels to specify the amount of time available. Default to the standard, one-week onboarding timeframe.
Send reminder messages when things are nearing their due dates, and reassign cases when time is becoming critical.	Use SLA Escalation procedures to automate those activities.
Prepare a welcome letter for new employees, customized with their personal information.	Create a Print Template that inserts the new employee’s phone number, email address, and login information.
Send a reminder message to the HR Rep, telling them when to expect the new employee.	Create an Email Template for the message. At the end of the onboarding preparation process, invoke a Rule that sends the message to the case owner.
Have differing processes for engineers and sales personnel, for example.	Define Case Types with additional process models, inheriting all of the standard process models from the parent Cases object.
Capability to diverge from the set processes	Ad Hoc Processes (multi-step tasks)

Designing the Application

While comprehensive design advice is outside the scope of this article, a few important principles dictate the best design sequence: 1.Design the data model first.

While it may be tempting to think in terms of the processes your organization follows, the best way to design the application is to focus on the data model at the outset.

The reason is that processes are attached to the objects that make up the data model. (An object is a data table that provides additional behaviors--such as processes, rules, and email--

which can be applied to any record in the table. So any given process is a built-in part of a specific object.)

If you start by building processes, on the other hand, you can easily design one that needs information from different objects. When you discover that problem later on, you’re forced to either :revise the model or create a linkage between those objects that would otherwise be unnecessary.

The simplest form of data model is an Entity Relationship (E/R) diagram like this one: