1 Case Overview

The Thinx! Case Management Module provides your organization with a central repository to manage, track and store information pertaining to a case. The module integrates seamlessly within the Thinx! Platform Framework to leverage its full capabilities, including automated workflow, to help your users process and resolve cases quickly and efficiently.

What is a case? A case may be a problem ticket, service desk request, System to link, organize all relevant information pertaining to a case. The Thinx! Case Management Module is a flexible, extensible features set which can be tailored to meet the needs of your organization.

To get started with the Case Management Module, it first must be enabled. Navigate to the My Account site area via the View My Account link in the Thinx! Platform. Once there, navigate to the Client Config page and click the Add Module link in the Actions drop down. Select Case Management and follow the prompts to enable the module.

For pricing information, see the Pricing page.

Once the Case Management module is enabled, case management Navigation Items will become available in Navigation Menu section. The following navigation items are available:

  • My Cases – The main starting point for most end users to create cases, work/triage cases assigned to them, view/manage unassigned cases.
  • All Cases – The main starting point for higher level administrators with access to find, view/manage cases within the organization.
  • Case Admin – Contains the configuration and administration functionality for case types.
  • Case Statuses – Contains the configuration for case statuses used within the module.

Using the Navigation links in the Navigation Menu section, provision the Navigation Items with any appropriate permissions as required. Next add the Case Management Navigation Items to the appropriate Navigation Source and publish the resulting menu. Users will need to logout and back in to see the menu. See the Platform Menu Maintenance documentation for more information.

Like all functionality within the Thinx! Platform, the Case Management module utilizes permissions for access control. Permissions are grouped together in roles and then assigned to users and/or groups. See the available Permissions within Case Management in section 3.1.

Note
By default, the system creates the Case Admin role when Case Management is enabled. The Case Admin role has CASE_ALL permission, and therefore may take any action in the system.

Administrators may customize or create new roles as needed. After any customizations are made, be sure to provision the necessary users with the appropriate Case Management role(s).

The following concepts are important to understanding the Case Management Module:

Case Type
A Case Type corresponds to a definition and set of configuration parameters for a succinct category of cases. When a case is created (a case instance), it must be tied to a case type.

Permissions may be applied to a case type and therefore restricted from certain end users.

An example of a case type could be Install Printer

Case Instance
A Case Instance is an occurrence of a case type. Every case instance must have a case type. End users create case instances when they wish to open a case. The behavior of the case instance is inherited from its case type.

Process
A process is a higher-level categorization of related case types. A Process can contain zero or more case types and a case type must belong to one and only one Process.

Permissions may be applied to a process and therefore may be restricted from certain end users. The permissions on the process have precedence over the permissions on the case type; if the user does not have permission on the process, but does have permission on the case type, then the process and all case types associated to it are restricted.

An example of a process could be Hardware Requests

Solution
A solution is the highest level of categorization of related processes. A solution can contain one or more processes and a process must belong to one and only one Solution

Permissions may be applied to a solution and therefore may be restricted from certain end users. The permissions on the solution have precedence over the permissions on the process(es) and case type(s). If the user does not have permission on the process, but does have permission on the process, then the solution, all processes and all case types associated to it are restricted.

An example of a solution could be Employee Actions

A Case Instance progresses through a series of pre-defined States. The case need not pass through all states, but others are required.

A case moves to another state via a Case Action. Case Actions can either by user initiated or system initiated. User initiated Case Actions are produced by the user clicking on the appropriate buttons in the UI on the Case Detail page or Case Edit form. Given the current state of the case, only the applicable buttons will appear.



The following diagram illustrates all of the possible Case States and the corresponding Case Actions responsible for the state transition:



The meaning of each state is as intended:

  • New: The case has been created, but not yet viewed or acknowledged
  • Opened: The case has been acknowledged and/or undergone an initial analysis
  • In Process: The case has undergone an analysis and is actively being worked
  • Resolved: The underlying issue/task has been fixed or resolved.
  • Completed: The resolution/fix for the case has been acknowledged by the case initiator or the appropriate amount of time has elapsed since the case was marked as Resolved.
  • Pending: The case requires some additional input from the case initiator or another user before it can continue
  • On Hold: The case requires some other related/unrelated action outside of the case. For example, if a system change needs to be made to an application before the case can be resolved.
  • Reopened: The case was marked as resolved, but the action did not resolve the case.
  • Cancelled: The case is no longer valid. A case can be cancelled at any point in its life time provided it is not closed.

The My Cases page is the main entry point for users into the Case Management Application. From this page, users may view and act on cases.

The My Cases page consists of three tabs:



My Cases tab
The My Cases tab displays all of the cases created by the user or initiated on behalf of the user. By default, all recent, in progress cases are displayed.

Assigned Cases tab
The Assigned Cases tab displays all cases assigned directly to the currently logged in user or assigned to a group to which the currently logged in user belongs. The cases appearing here typically need to be actioned by the logged in user or a member of their group. By default, all recent, in progress cases are displayed.

Unassigned Cases tab
Cases not assigned to any user or group appear on the Unassigned Cases tab. By default, all recent, in progress cases are displayed.

Cases may be created through the Application UI by navigating to either the My Cases or All Cases pages for users with the necessary authorization. Case administrators are responsible for granting all access, including case creation.

Step 1: Click the Create Case option in the Action drop down




Step 2: Select the Appropriate Case Type
In the Create Case popup, select the appropriate Solution, Process and Case Type. If the case initiator has access to only one Solution and/or Process, then the Solution/Process fields may not render. The Case Type must be selected.




Step 3: Fill out the Create Case Form
After the case initiator selects the appropriate case type, the corresponding Create Case form renders. The Case Form consists of several main sections:

  • Basic Information
  • Additional Information
  • Extended
  • Case Documents

Required fields are noted with an asterisk.

The Basic Information, Additional Information and Case Documents sections appear on all Create Case forms, regardless of the case type selected. These sections contain fields which are considered structured attributes: they are relevant to cases across many different functional domains. The following fields are considered structured attributes:

  • Initiator Type: Either User or Customer. In order for Customer to be an option, the CRM Module must be enabled.
  • Initiator: Type ahead search driven by the type selected in the Initiator Type drop down. If User is selected, searches against the configured users in the Thinx Platform Framework; if Customer is selected, searches against the active customers in the CRM Module.
  • Assigned To: The user(s) or group(s) assigned to whom the case will be assigned. If the underlying case type has an Assigned To Workflow configured, then this field will not be visible on the create case form as the workflow will determine the assigned to user(s) and/or group(s) on case creation. This field is not required.
  • Location: The locations configured in the metadata framework. If no location schema is selected in the Case Administration section, then this drop down will not appear.
  • Priority: Drop down containing a list of predefined priorities.
  • Description: A brief summary description of the case problem/issue.
  • Details: The detailed supporting information for the case.
  • Due Date: The due date for the case instance; this can be created either manually set by the user or computed dynamically based on the underlying case type’s configuration.
  • Percent Complete: Available after the case is created on the case instance edit form and only if complete percentage options are assigned to the case type via Case Administration.
  • Tags: User entered categories to help with reporting/classification of case instances.
  • Case Documents: Documents uploaded and associated to the case instance.

The Extended section is specific to the case type and contains the fields configured by the case administrator to appear. These fields are considered as unstructured attributes and may or may not be required, depending on the configuration. The configuration utilizes the metadata framework within the Thinx! Platform.

Special attention should be paid to the Initiator fields in the Basic Information:



Case Initiators may be asked to open a case on behalf of someone else, for example in a call center situation. Therefore, the initiator may be changed on the Create Case form. Currently, two Initiator Types are supported:

  • User – if selected, allows case initiators to search for users in the system
  • Customer – if enabled by the case administrator, and if selected, allows the case initiators to search for customers in the CRM.

It will default in with an Initiator Type as User and the value of the Initiator field as the currently logged in user. The value of this Initiator field is changed, then the value will be displayed as the initiator throughout the application.

Step 4: Submit the form
After all of the required and desired fields are filled out in the Create Case form, the user clicks the Save button to create the case. Upon case creation, the form is saved to the system, the Assigned To user(s)/group(s) are dynamically assigned (if configured), and any notifications are generated and sent (if configured).

The Case appears in the case initiator’s My Case tab, as well as the Assigned To user(s) Assigned Cases tab. If the case was not assigned during case creation, it will appear in the Unassigned Case tab.

Cases may be assigned to user(s) or group(s). This assignment is made either explicitly or dynamically via a configured workflow. The case assignment option is determined by the configuration assigned to the Case Type selected by the initiator. Administrators configure the assignment mechanism during the Case Type set up.

Cases need NOT be assigned to a user or group during case creation. However, they should ultimately be assigned out in order to be moved through the states in the Case State Model.

When the explicit assignment option is enabled, an Assigned To field appears on the Create Case form. The Assigned To field is a type ahead field enabling the user to search for an existing user in the system.



Currently, the Assigned To field only supports user search, therefore, only users can be explicitly assigned to a case.

The case assignment may be changed at any time by updating the Assigned To field, provided that the current logged in user has access to update the field.

When the dynamic assignment option is enabled for a case type, the case initiator fills in the configured fields on the Create Case form. Once the Save button is clicked, the information entered by the initiator is sent through a decision tree workflow attached to the case type, and a user or group assignment is made. The case will automatically appear in the assigned user(s) Assigned Cases tab. The case initiator may also view the case assignment when the case appears in the My Cases tab. On the Case Details page, the Assigned To field will appear as read only.




The case administrator is responsible for building the decision tree workflow and attaching it to the required case type(s). Each case type may have its own decision tree.

The case assignment Cases dynamically assigned a user(s) or a group(s) may be overridden on the Case Edit form, by clicking the Edit Assigned to checkbox. This changes the Assigned To field to become editable allowing the user to remove the current assigned to group(s) and/or user(s), or manually add users:



Currently, only users may be added in this way. The currently logged in user must have access to the Edit Assigned To checkbox in order for this functionality to be enabled.

If configured, upon save, newly assigned users will receive an email notification informing them that a case has been assigned to them.

When a case is assigned to a group(s), it appears in the Assigned Cases for all users belonging to that group. In order to facilitate a chain of custody for the case, an individual user may “claim” the case, by clicking on the Claim button.



Claiming the case has the effect of changing the Assigned To field to the person who claimed the case:



The Assigned To field will appear as the claimed user throughout all views of the application.

The group assignment is NOT lost. The user who claimed the case may decide later to “un-claim” the case. “Un-claiming” the case will revert the Assigned To field back to the Assigned To group.

Even if a case is claimed by a user, the Edit Assigned To checkbox will appear in the Edit Case form allowing the Assigned To user to be manually overridden. This has the effect of “Un-claiming” the case for the initial Assigned To user and “claiming” the case for the new Assigned To user.

Existing cases may be changed/edited from the UI through the Case Details page, provided that the user has the appropriate permission to edit it. Navigate to the Action Menu and click the Edit Case option to open the Edit form.



The end user then makes the necessary changes and then clicks the Save button. The Save button does NOT change the state of the form, so no state change notifications are generated.

Some fields may be edited/changed on the Case Details page itself. For example, users may add comments and tags directly in the Additional Information section:



Once the person assigned to action the case has completed all of the required tasks or steps, they mark the case as Resolved by clicking the Resolve Button. Click the button will prompt the user to enter a resolution:



The Resolution field is required. After providing an appropriate resolution and clicking the Resolve Button, the case will be set to the Resolved state. The resolution may later be viewed by opening the Case Details page.

Most likely, the person resolving the case should not have access to complete the case.

When a case instance is marked as Completed, it reaches its end state and is considered closed. Typically, either the case initiator will confirm the case is indeed resolved by manually completing the case by clicking the Complete button on the Case Details page or the underlying case type may be configured to automatically close after a certain number of days.

Interested parties may be added to individual existing case instances. Whenever there a state change, update or SLA warning or violation occurs, watchers will also be notified. To add a watcher to the existing case, navigate to the case details screen of the case instance and launch the Add Watcher dialog popup found in the Action menu.



The Manage Watchers popup will display. Start typing the name of the watcher to add. Once found, select the watcher name to add them to the watcher table.





Once all the watchers are added, click the Save button.

  • casemanagement/overview.txt
  • Last modified: 2020/04/09 15:07
  • (external edit)