Case States and Case Actions

Case states and case actions provide a powerful case management tool, allowing a user to choose the most appropriate actions to perform on a case at a particular point, according to the business context of the case.

Cases (for example, claims or orders) flow through states that are particular and specific to the type of case itself. For example, an order may be in one the states "submitted", "fulfilled", "dispatched" and "delivered". Based on the state of the case, there may be one or more applicable actions that a user might need or want to perform. What actions are required, in what order they are performed or indeed whether an action is performed more than once is at the discretion of the user working on the case. Implementing case states and case actions for a case class gives users the ability to make these decisions and perform the required actions.

At design time, you must:

  1. define a case state for the case class.
  2. define the set of case actions that are required to support the case.
  3. for each case action, define the case states in which it will be available, and the permissions a user needs to be able to use the case action.

At runtime, when a user has located a particular case, the case actions are displayed that are available to them and appropriate for the current case state. They can then decide which, if any, of these actions they want to perform based on the particular case circumstances.

Case States

A case state is a special type of attribute, available only on case classes, that can be used to uniquely identify a set of business-specific states that a case can be in.

A case class has only a single case state attribute, which must be a text property type whose enumeration type lists the possible states of the case object.

Note: As cases live outside of individual processes, at some point the data will become redundant (for example, a case representing the tracking of an invoice might not be required after a 1 year retention period after the invoice is paid). Therefore all case types must define one or more states in which a case can be considered redundant and therefore can be deleted permanently. Select one or more terminal case states (which indicate that a case is complete and can be deleted.) These are selected on the case state and that there must be at least one terminal state (so that the case can ultimately be deleted).

Case Actions

A case action is a special type of business service, associated with a case class, that defines an action a user can perform on a case. You can either create a new case action or generate one directly from a case class. Template case action processes are provided that allow you to view or update the contents of a case object, but you can modify these templates to provide whatever functionality you need for a particular case class.

You can define as many case actions as you need for a particular case class. The set of case actions define all the actions that a user could perform on a case. You can then restrict the availability of these actions by case state and user privileges:

  • Case state: You can specify that a case action is only available when a case object is in a specific case state (or states). For example, if you have defined a case action to update delivery details for an order, you may want to restrict this to be available only for orders that are "submitted".
    Note: Case actions cannot be made available in terminal states, because terminal states indicate that the case is complete.
  • Privileges: You can specify that a case action is only available to users who have a specific set of privileges. For example, in a call center, you may want to make certain actions available only to supervisors.

At runtime, a case action can only be invoked for a particular case object, either from the Case Manager or, in a custom client, by using the BusinessService API service.