Defining case statuses

From PegaWiki
Defining and applying case statuses / This is the approved revision of this page, as well as being the most recent.
Jump to navigation Jump to search

Defining case statuses

Description Defining case statuses
Version as of 8.7
Application Pega Platform
Capability/Industry Area Case Management


When designing an application, it is important that the status values hold meaning for the business and are not thought of as technical constructs.

Some questions you might ask yourself when choosing status values are as follows:

  • What does the business want to report on while work is in-flight?
  • What about after the fact, when the cases are resolved?
  • How might the business want to group cases by status?
  • What are the major events that would trigger a status change?

The case status should complement the other pieces of data associated with a case, including the stage and the assigned operator or workbasket, in order to provide information that best describes the disposition of the case. Keep in mind that you want to have as many statuses as necessary but no more. A best practice is to have no more than 10 statuses for a given case type. Finally, statuses should be as consistent across case types as possible.

Intentional alphabetic order of case statuses[edit]

Case statuses are typically prefixed with New, Open, Pending, or Resolved. This is intentional and can be very useful when viewing lists of cases and sorting by status. As a best practice, use these four prefixes for your case status values.

The case status prefixes are often followed by a hyphen and a meaningful suffix. For example, Pending-Approval is used to indicate that a case is in a pending status awaiting an approval of some kind. Case status suffixes should indicate a meaningful business context that complements the New, Open, Pending, and Resolved prefixes.

Importance of prefixes[edit]

There are several capabilities in Pega Platform™ that rely on the prefix of a status. This is used by those features to include or exclude cases based on their status. For example, a 'work resolved by operator' report will exclude cases that are 'Resolved-Cancelled' as this is not considered resolved work for that operator.

Pega's 'work resolved by operator' report, filtered to exclude 'Resolved-Cancelled' status

All closed cases should have a status with the Resolved prefix. For example, there are many reports and other types of case behavior that look for statuses that begin with Resolved to determine if a case is closed. The suffix of a resolved case should indicate its final disposition, for example Resolved-Completed or Resolved-Cancelled.

Pega's PyTopCasePerformers report, using a filter of 'does not start with' the letter 'R' to avoid showing any resolved case.

It is highly recommended to retain the Pega status nomenclature using prefixes to avoid having to refactor features that tie into the status. If requirements dictate the need to have new prefixes or remove all together consider this carefully. You may want to explore field values as a way to translate the status to the required name, avoiding the need to refactor statuses for features that use them.

Related information[edit]

Case status values

Changing case statuses

Defining a custom case status