Case Type - Lifecycle

Case types that involve multiple users and multiple potential outcomes have complex lifecycles. Before you can design a case type's lifecycle, it's important that you thoroughly understand the concepts described under Lifecycle and Status-Specific Business Rules. After thoroughly understanding these concepts, we recommend you perform the following design steps:

• Draw a "state transition diagram" as illustrated above under Lifecycle. Keep in mind that if your state transition diagram is complex, your cases will be complex. While some cases warrant complexity, you should always ask yourself if there aren't better ways to achieve the desired results if your first effort results in complexity.
• Determine which characteristics (if any) are required during each stage of a case's lifecycle
• Determine when To Do entries (if any) should be created (and completed) during a case's lifecycle
• Determine additional validation (if any) that should be executed before a case enters and exits each state
• Determine additional processing (if any) that should transpire when a case enters or exits each state
• Determine if scripts are warranted to help users work the cases and, if so, design the scripts for each applicable state

When the above tasks are complete, you will be ready to set up a case type's lifecycle.

Open the Lifecycle page by selecting Admin > Case Type > Case Type > Search and navigate to the Lifecycle page.

Main Information

The Status accordion contains an entry for every status in the case type's lifecycle.

Use Status to define the unique identifier of the status. This is NOT the status's description, it is simply the unique identifier used by the system.

Use Description to define the label that appears on the lifecycle accordion as well as the status displayed on the case.

Use Script to reference a BPA script that can assist a user work on a case while it's in this status. Refer to A Script That Helps A User Work Through A Case for the details.

Use Access Mode to define the action associated with this status. This field is disabled if an application service is not specified on the Main page. Refer to Access Rights for the details of how to use this field to restrict which users can transition a case into this state.

Use Batch to specify a batch control that will auto-transition the case. Any case in a status configured with a batch control will be transitioned when the batch job runs (rather than when CASETRAN is executed). For this purpose, batch process C1-CSTRS ( Case Scheduled Transition) is supplied with base package, which will execute all Exit Status logic for the current status, and Enter Status logic for the destination status. You may choose to create a batch process with your own transition logic.

Use Comment to describe the status. This is for your internal documentation requirements.

Use Sequence to define the relative order of this status in the tree on the Main page.

Use Status Condition to define if this status is an Initial, Interim or Final state. Refer to One Initial State and Multiple Final States for more information about how this field is used.

Use Transitory State to indicate whether a case should ever exist in this state. Only Initial or Interim states can have a transitory state value of No.

The Alert Flag is used to indicate whether or not an alert should be displayed for customers with cases in the state. (The alert is shown via the base package Installation - Alert algorithm.)

Algorithms

The Algorithms grid contains algorithms that control important functions for cases of this type. You must define the following for each algorithm:

• Specify the System Event with which the algorithm is associated (see the table that follows for a description of all possible events).
• Specify the Sequence Number and Algorithm for each system event. You can set the Sequence Number to 10 unless you have a System Event that has multiple Algorithms. In this case, you need to tell the system the Sequence in which they should execute.

The following table describes each System Event (note, all system event's are optional and you can define an unlimited number of algorithms for each event).

Next Statuses

Use the Next Statuses grid to define the statuses a user can transition a case into while it's in this state. Refer to Valid States versus State Transition Rules for more information. Please note the following about this grid:

• Use Action Label to indicate the verbiage to display on the action button used to transition to this status.
• Sequence controls the order of the buttons that appear on Case - Main. Refer to Buttons Are Used To Transition A Case Into A State for more information.
• Use as Default controls which button (if any) is the default button.
• Transition Condition may be configured to identify a common transition path for cases of this type in the current state. This transition condition may then be referenced across multiple case types. You'll need to add values to Look Up table field TR_​COND_​FLG that fit the typical transitions for your case types (e.g. Ok, Error, etc.).

By assigning the transition condition value to a given "next status", you can design your Enter State transition or Auto-Transition logic to utilize those flag values without specifying a status particular to a given case type. Thus, similar logic may be used across a range of case types to transition a case into, for example, the next Ok state for the case's current status.

• Transition Role controls whether only the System or both System and User have the ability to transition a case into a given "next status".
• You can use the status description hyperlink to open the Status accordion to the respective status.
• When you initially set up a case type, none of the statuses will reside on the database and therefore you can't use the search to define a "next status". We recommend working as follows to facilitate the definition of this information:
  • Leave the Next Statuses grid blank when you initially define a case type's statuses
  • After all statuses have been saved on the database, update each status to define its Next Statuses (this way, you can use the search to select the status).

Required Characteristics

Use the Required Characteristics grid to define characteristics that are required when a case enters this state. Only Optional characteristics defined on the main page appear in this grid. Refer to Required Fields Before A Case Enters A State for more information.