The OpenText Process Suite ABC Glossary - Case Model

Case Model

One of the most important differences between a business process model versus a case model is flexibility. A case model or case management process offers flexibility in the execution of the steps or the activities to reach to an acceptable resolution of the case.

A business process model consists of a number of clearly defined steps from the process start to the end, where the end represents a clear target that will be achieved by executing the process.

A case model is typically focused on problem solving, like incident or issue management, investigative research, claim or complaint handling, service requests, mortgage or loan applications, etc. In these examples, there is no clear and definite set of activities to work to a correct or acceptable resolution of the case, but it is much more driven by the contents of the case and the knowledge of the case worker to decide on how to resolve the case. The case worker decides on which activities must be performed in order to reach to a final acceptable point with the case. Case models support non-sequential processing and event handling capabilities into one single model. Similar to the business process model, a case model has one single starting point, but can have multiple end points.

In addition, a case model is concentrated on a case file or repository containing important documents (pictures, word processing documents, notes, video snippets, etc.) that are relevant to the case and support the case worker to decide on the dynamics of the case as well as document the arguments for justifying the decisions made while handling the case.

Imagine you are visiting your GP (General Practitioner), you would not like your physician treat you by means of a process model (step one, step two, step three and here is your prescription) with no flexibility at all. The case model offers your GP the flexibility to decide on any steps to be performed in order to treat your complaint, including executing the same step numerous times to reach any of the goals (end points) defined, for example, complete or partial recovery, or in the worst case scenario have the case terminated instantly due to the passing away of the patient. These kind of sudden events can be implemented in a case model as well, by defining the event (“Patient has deceased”) which subsequently can be triggered with any number of the activities that are part of the case model.

A case model empowers the case or knowledge worker to decide on which of the proposed activities are relevant and need to be performed in order to provide a resolution to the case. The case model as such provides a repertoire of activities from which the case worker dynamically creates and manages the task list of activities.  Case models are divided into different states or phases. Typically with problem solving assignments, you start with analysing the problem, once determined the root cause, you will start to work on resolving the problem. In a case model, you can model this using two states: analysis phase and resolution phase. 

In each of the phases, you will then model the possible activities that can be performed in this state. Transition rules determine on which condition(s) to move from one state into the other state or vice versa. Case models are executed through a state engine.

With reference to the doctor’s visit, the case model may include at least two states i.e. the diagnostic phase and the treatment phase, enabling your GP to switch between these states depending on how the case progresses.

The OpenText Process Suite (OTPS) platform includes a graphical editor to design the visual case model. While you are designing and implementing your case model(s), you can validate, build and publish the model to test run the execution of your case model. When building and publishing, the case model design and implementation is translated into SCXML (State Chart XML). SCXML is used to represent the executable version of the case model and can be run by the state engine as part of the OTPS platform. When you run a case model, the system creates a case instance that can be administered by means of the Case Instance Manager  artifact.

While designing the case model, the designer has the choice between different types of connector between the activities. This defines the relation between these activities and thus models the flexibility of the case:

1. Automatic follow-up

When activities A and B are linked automatically this means that the next task B will be automatically added to the dynamic list of tasks of the case instance. As soon as the case worker has completed task A, task B is added to the task list. This still leaves the case worker with the possibility to remove the task from the list. Unless the task is modelled as a mandatory task.

2. Manual follow-up

When activities A and B are linked manually, this means that as soon as the case worker has completed the preceding task A, task B is proposed as a next step, however the case worker needs to manually confirm the task to be added to the task list. This dynamically builds the task list.

3. Intermediate follow-up

Activities A and B are linked through intermediate follow-up, this means that initially only task B is added to the dynamic task list, and task A will be added to the task list as soon as the case worker has completed task B. By means of the intermediate follow-up task A is defined as being dependent on the completion of task B. You can use this kind of relation to model the conditional execution of one task as dependent on completing another task first.

4. Free follow-up

This is an activity in the case model that has no connector to any of the other tasks in the case model. This means that the case worker can add this activity to the task list at any moment while working in the case instance as well as any number of times this task can be added, completed and added again.

When running the case instance, the case worker decides on proposed activities to be added to the task list, thus dynamically managing the relevant activities included in the task list to resolve the case. When completing any of the listed tasks, the case worker is enabled to decide on any next task(s) to be added to the task list. The case designer provides this kind of flexibility by adding the appropriate activities to the case model and allowing for any type of follow-up between tasks or no follow-up implying that this activity can be selected at any moment while working on the case as well as allowing the activity to be added to the task list any number of times.

By means of the OpenText Process Suite (OTPS) platform Inbox  artifact, the case worker interacts with the case instance. The inbox provides the functionality for the case worker to decide on the activities to be taken as next steps to resolve the case, and thus dynamically build and manage the list of tasks to complete the current state of the case and / or decide to resolve the case instance through any of the possible end points designed in the case model.

The OpenText Process Suite ABC Glossary contains a description of the important keywords and concepts of the OpenText Process Suite (OTPS) platform. It is not meant to be a complete list but can help you to master and comprehend the most important concepts and technologies of the OTPS platform. You can also find a list of abbreviations below that are used with the descriptions of the listed keywords. 

Watch our OnDemand webinar on case modeling here

List of abbreviations