Creating a Case Manager Definition
Last updated
Last updated
Contact Us
Get Help© Copyright TomorrowX 2024 Composable Architecture Platform and Connected Agile are trademarks and servicemarks of TomorrowX.
Each case manager has a number of core components that can be created through the console. This section lists the various parts and how they fit into the overall picture of the case manager.
Before you can define anything for a case manager, it must have a connection to a database. This is achieved using a JDBC connection. Select the Case Manager Setup section in the administration tree.
Make sure that the database exists if necessary (the Derby based demo database will auto-create it, but most other database systems will not). Then specify the database name and driver and click Create. The database will appear in the administration tree and the case manager management page will be presented.
From the previous page you can also upload a previously saved definition. Definitions are stored in XML files with the extension type “.cms”.
Once the database definition has been created, it will normally not contain any definitions at all (unless you are connecting to an existing case manager database). So, you will be presented with the following page:
At this point you can import an existing definition (often a good starting point to avoid beginning from scratch). If so, you will see all of the case manager components from that definition appear in the tree below the case manager. We will now cover those components in detail.
Central to the case manager is the concept of queues. Whenever a new case is created, it is assigned a task that in turn is connected to a work queue. Users of the case manager can organize their work and manage basic workflow by using the queues. For example, the default definition has queues for emergencies, customer calls, quality assurance, rules review and so on.
Through the user roles, queues can be designed to be auto-picked from or simply be a holding pattern for specific tasks. At times it may be relevant to create queues for each staff member or role, to allow these staff members (or a supervisor) to assign specific tasks to specific individuals.
To add or update a queue, select the Queues section under the name of the case manager in the Case Manager Setup section in the administration tree.
Queues have priorities (where the lowest number means the highest priority) so that an auto-pick always pick from the lowest numbered queue first.
As a good rule when assigning priorities to queues, make the lowest 100, the next one 200 and so on. This will allow you to later comfortably insert another queue into the priority chain (for example, 150) without having to change too many queues.
Also notice the small “globe” icon next to the Default description. Clicking this icon allows you to edit the multi-lingual parts of a case manager definition. This concept is replicated for each case manager component that may require translation and clicking the icon presents you with a screen similar to this:
The languages shown are each of the languages available for the console.
Status codes are used to indicate if a case has reached a conclusion or is still a work in progress. As a minimum a blank status code MUST exist to indicate cases that are open. Other status codes are mainly used for statistical and reporting purposes.
Even if a case is closed, it is still possible to have active tasks against that case (for example quality assurance or rule reviews).
Since a case manager is multi-lingual, any lists boxes showing a selection of values must have a description associated with each list entry that is translatable.
These list entries are used in fields.
Fields are associated with tasks and are used to contain structured or important mandatory information that must be captured for each task. For example, for a “Call Customer” task, it may be relevant to record the name of the person called and the phone number used.
Fields can either be mandatory or optional, contain an input field or a list and can have a validation rule. The following shows a free format input field for an email address, which in turn is validated using a regular expression. For more information on regular expressions, see the rules reference.
Alternatively, fields can contain a list of list entries:
The list values are the list entries created previously.
Selections refer to the name of actions that can be taken when a task is completed. These selections can have actions linked to them (see below).
A single selection can result in one or more actions being taken.
Actions are what adds the dynamical workflow to the case manager and allows for a predetermined, predictable case management experience. Actions are taken when a user makes a selection to complete a task (see below).
Actions also allow for a dynamic review of the performance of the user of the case management system. By setting a percentage of cases that needs to be reviewed, the case manager can randomly pick these cases out and assign them to a quality assurance queue for review.
Actions can also delay when the next task becomes due for action. This way, tasks that require a later follow up will automatically come to your attention when required, and then flow back into the normal queue priorities.
Tasks are the final part of the case manager setup. A task is a representation of something that needs to be done to move the case to its next step.
A given case can have more than one task pending. For example, you may have both quality assurance and rules review pending on the same case at the same time.
A task can have fields associated with it. These are the fields defined earlier. Each field serves as a means of collecting data relevant for that task.
Finally, each task has a number of selections. These selections represent the actions that can be performed once a given task has been completed. Any one of these selections can result in one or more actions (see Actions above).
Once you have completed the setup of your case manager definition, you can export it to an XML file. The file will appear under the Case Manager Setup with the same name as the case manager.
If you select it, you can download it for future reference, or to define another case manager.
Just like data files, and other files in repositories, case manager definition files are versioned automatically within the console and you can restore a previous version if required.
At times (if you are comfortable with XML files and you have a lot of definitions to enter), it can be quicker to edit the XML file directly and upload it to the console.
If you import a new definition file, be aware that it will update/add itself to any existing definitions and will not remove any existing entries.
The user roles can be used to set very specific authorities for the access of a user to the various parts of the case manager. Please see the Managing User Roles section for an in-depth discussion on roles.
The following shows a sample role setup:
This is a user role that shows a basic fraud analyst role. Some tasks (such as quality assurance and staff training) are omitted, as are certain queues. This distinction makes it possible, as an example, for a supervisor to manage those same tasks within the case manager, without the analyst being able to see the result of QA reviews or training requirements.
