Case Type - Lifecycle

Case types that involve multiple users and multiple potential outcomes have complex lifecycle. 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:

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 and navigate to the Lifecycle tab.

Note:

You can navigate to a status by clicking on the respective node in the tree on the Main tab. You can also use the hyperlinks in the Next Statuses grid to display a specific status in the accordion.

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 to 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.

Note:

If you wish to defer transitioning a case in a particular status until the batch process on your case type status is executed, you should not populate an Auto-Transition algorithm on that status. Otherwise, CASETRAN will transition the case according to your Auto-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 taxpayers 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:

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).

System Event

Description

Auto Transition

This algorithm is executed to determine if a case that's in this state should be transitioned into another state. Refer to Automatic Transition Rules for the details.

Click here to see the algorithm types available for this system event.

Enter Processing

This algorithm holds additional processing that is executed when a case is transitioned into this state. You can also specify state transition logic within Enter Processing routines. Refer to Additional Processing When Entering A State for the details.

Click here to see the algorithm types available for this system event.

Enter Validation

This algorithm holds validation logic that executes before a case can enter a given state. Refer to Validation Before A Case Enters A State for the details.

Click here to see the algorithm types available for this system event.

Exit Processing

This algorithm holds additional processing that is executed when a case is transitioned out of this state. Refer to Additional Processing When Exiting A State for the details.

Click here to see the algorithm types available for this system event.

Exit Validation

This algorithm holds validation logic that executes before a case can by transitioned out of a given state. Refer to Validation Before A Case Exits A State for the details.

Click here to see the algorithm types available for this system event.

Script Launching

This algorithm sets the script launching option for the script associated with a given state, if any. Refer to Script Launching Option for the details.

Click here to see the algorithm types available for this system 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:

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.

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.