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 customizations 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!