Difference between revisions of "Defining and applying case statuses"

From PegaWiki
Jump to navigation Jump to search
Line 27: Line 27:
  
 
{| class="wikitable"
 
{| class="wikitable"
|-
 
 
| row 1 cell 1
 
| row 1 cell 1
 
| row 1 cell 2
 
| row 1 cell 2

Revision as of 19:35, 17 July 2020

Defining and applying case statuses

Description
Version as of
Application Platform
Capability/Industry Area

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.

Case Status Prefixes are Intentionally Alphabetic

You may have noticed that 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. Pega recommends using 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 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.

The Resolved prefix is important and has special meaning test

All closed cases should have a status prefix of resolved. There are several capabilities in the Platform that rely on this. For example, there are many Reports and other case behaviors 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.

The following is a list of field values provided with the Platform that follow the recommended naming convention:

{