Defining Case Types in Pega's App Express

The third step in settings up a new Pega application through App Express lets you define your Case Type names and descriptions. But what exactly is a case type? And what actually constitutes a case instance? Let´s give a little more background to add color to the rich palette of business rules. Pega´s glossary documentation states the following:

A case type represents work in your application that follows a life cycle, or path, to completion. Each case type has a hierarchical structure and can include attachments that provide relevant details about the work that you are processing.

In practice, each case instance just holds all Properties (name and value) associated with that case. For example, these properties can be numbers, dates or text entered by the case worker or sourced from some other system. In this regard one could think of a case as a digital folder or dossier of certain type. That brings us to the developer´s perspective on a case type.

In Pega, a case type is meant as a generic interactive work related business process class (pyDefault) defining the Data model, Life cycle with stages & steps, Views (since 7.2) as well as configures certain additional business functional Settings. These settings include Attachment categories, Goal & deadline, Notifications (push to mobile) and the Parties (pyCaseManagementDefault) involved.

Related Rules

Apart from the above build-in definitions and settings, this umbrella (Work class) typically contains associated process flow, actions, screens, etc. to support the data and its life cycle. Here´s a simplified UML class diagram with the main rules and relations one could expect within a case type definition in PRPC. To jump start your thinking here are a few examples of good case types per industry:

Industry	Case Type(s)
Finance	Deposit, Savings Application, Mortgage, Reversal
Government	Advice, Investigation, Hearing, Law Case
HR	Interview, Onboarding, Vacation
Insurance	Annuity, Claim, Liability, Quote

In my experience, when introducing Pega to a new project team, start out with a single application with only two at most three (technically unrelated) case types. That way people can keep sufficient focus on development and delivery while collaborating in DCO sessions without running the risk of working all on the same business rules (checkout locks).

To conclude with the App Express screen where we came from: Perhaps you cannot think of all the case types right away. Don´t worry because you can define those later on; through the Case Explorer on the left side panel.

---

This is the third article in a series about the screen flow steps in Pega´s App Express:

1. Application settings
2. Business objectives
3. Case types
4. Data types

[Edgar] (3/10/2017 10:09:46 AM)