3.3 Optional Actions, Approvals & Case Resolution

3.3 Optional Actions, Approvals & Case Resolution

CSA Exam Focus: Enterprise business operations rarely follow a purely linear path. The Certified Pega System Architect exam heavily emphasizes non-linear patterns, including Optional Actions (User Actions vs. Processes, Stage-only vs. Case-wide), multi-tiered Cascading Approvals (Reporting Manager vs. Authority Matrix), and proper case resolution mechanics using standard status conventions.

---

Optional Actions: Enabling Non-Linear Workflows

While the primary stage lifecycle defines the expected, standard path of a case, users frequently need the ability to perform ad-hoc, discretionary activities outside the normal sequence of steps. Pega provides Optional Actions to support these requirements without cluttering the primary case progression.

Scoping Optional Actions: Stage-Only vs. Case-Wide

Optional actions can be scoped in two distinct ways within Case Designer:

1. Stage-Only Optional Actions: Configured under the Workflow tab of a specific stage. These actions are accessible to operators in the User Portal only while the case currently resides within that stage. For example, during an Underwriting stage, an underwriter might have a stage-only action to Request Supplemental Medical Records. Once the case advances to the Policy Issuance stage, that action disappears from the user's available actions menu.
2. Case-Wide Optional Actions: Configured under the Workflow > Case-wide optional actions section. These actions are globally available throughout the entire case lifecycle, across all primary and alternate stages, until the case reaches resolution. Examples include Update Contact Information, Add Case Note, Change Beneficiary, or Withdraw/Cancel Case.

Optional User Action vs. Optional Process

Within either scope, an optional action can be modeled as either a single-step action or a multi-step process:

In the Pega Constellation or Theme Cosmos user interface, optional actions are exposed to end users through the Actions menu on the case summary header or workspace panel.

---

Approval Workflows: Single vs. Cascading Approvals

Approval steps represent checkpoints where designated stakeholders evaluate case information and decide whether work should proceed, be rejected, or be routed back for rework.

Single Approval Step

Configured directly in Case Designer by adding an Approve/Reject step. Pega allows routing single approvals to:

• Specific User: Routes to a designated operator's personal worklist.
• Work Queue: Routes to a shared functional queue (e.g., FinanceApprovals@Finance).
• Reporting Manager: Routes dynamically to the submitter's direct manager based on the operator's organizational hierarchy.

When configuring an Approve/Reject step, the architect designates what occurs upon rejection: the case can advance to an Alternate Stage (e.g., Rejection), resolve immediately with a status of Resolved-Rejected, or route back to a previous stage for correction.

Cascading Approvals

Many business processes require multi-tiered governance where a single sign-off is insufficient. For instance, high-value expenditures, sensitive security access requests, or complex insurance claims demand multiple successive approvals before execution. Pega supports this through Cascading Approvals.

Pega provides two distinct cascading approval models:

                                +---------------------------------+
                                |    Cascading Approval Model     |
                                +----------------+----------------+
                                                 |
                   +-----------------------------+-----------------------------+
                   |                                                           |
                   v                                                           v
    [Reporting Manager Hierarchy]                                     [Authority Matrix]
    - Based on organizational chart (pyReportTo)                      - Based on business rules & decision tables
    - Follows direct supervisory chain                                - Routes to arbitrary, cross-functional approvers
    - Evaluates approval levels or thresholds                         - Populates an Approver Page List property
    - Best for: Internal expense reports, PTO                         - Best for: Capex, Legal, IT Security, Matrix orgs

---

Cascading Approval Pattern 1: Reporting Manager Hierarchy

The Reporting Manager model routes approvals sequentially up the submitter's management reporting chain. Pega navigates this hierarchy using the pyReportTo property stored on the operator record (Data-Admin-Operator-ID).

Configuration Options

In Case Designer, when selecting Cascading Approval based on Reporting Manager, the architect configures the stopping criteria:

1. All Managers in Hierarchy: Routes to the direct manager, then that manager's manager, continuing all the way to the top executive in the organization structure.
2. Custom Approval Threshold / Levels: Evaluates a business condition or threshold (e.g., purchase total). For example:
   • Purchases up to $1,000: Approved by Direct Manager (pyReportTo).
   • Purchases up to $10,000: Requires 2nd-level Director approval.
   • Purchases over $10,000: Requires 3rd-level Vice President approval.

Once an approver at or above the required approval level submits an approval, the cascading approval completes, and the case advances to the next step.

---

Cascading Approval Pattern 2: Authority Matrix

In modern matrix organizations, approval authorities rarely align strictly with an employee's direct line manager. Approvals often depend on multiple dynamic case attributes—such as product category, risk classification, geographic region, and total dollar exposure. Furthermore, required approvers may include cross-functional specialists (e.g., Legal Counsel, Compliance Officer, Chief Information Security Officer) who exist entirely outside the submitter's management chain.

For these scenarios, Pega provides the Authority Matrix cascading approval pattern.

Architectural Components of an Authority Matrix

An Authority Matrix relies on three coordinated components:

1. A Page List Property: A collection property on the case type (commonly named .ApproverList and typed to Embed-ApprovalList or a specialized data class). Each page in the list represents an approval step and contains properties such as .pyApprover (operator ID or work queue) and .pyApprovalLevel.
2. A Decision Table: Evaluates case attributes (e.g., .Department, .TotalExpense, .ContractRiskTier) and returns the designated approver and required role.
3. A Data Transform or Activity: Queries the Decision Table, iterates across business rules, and appends the necessary approver records onto the Page List property before the approval step executes.

Step-by-Step Configuration of an Authority Matrix Approval

Step 1: Define Data Model
Create Page List property on Case Type: .ApproverList (Class: Embed-ApprovalList)

Step 2: Build Decision Table (e.g., DetermineApprovers)
Condition Columns: .ExpenseType | .AmountThreshold | .Department
Action Column: Return Approver Operator ID (e.g., "cfo@company.com", "legal_lead@company.com")

Step 3: Populate Page List via Data Transform
Execute Data Transform during stage entry or pre-approval routing.
Data transform appends rows to .ApproverList with .pyApprover and .pyApprovalLevel.

Step 4: Configure Approval Step in Case Designer
- Step Type: Cascading Approval
- Approval Model: Authority Matrix
- Approver List Property: .ApproverList
- Approver Identifier: .pyApprover

When the case reaches the Cascading Approval step, Pega automatically iterates through .ApproverList, generating sequential approval assignments for each operator or work queue on the list. If any approver rejects, Pega halts the cascade and routes the case to the configured rejection path.

---

Case Resolution Best Practices

Case resolution marks the official conclusion of a case lifecycle. A case should only be resolved when all business goals have been achieved or when work is formally abandoned, rejected, or cancelled.

The Update Status Smart Shape and Stage Resolutions

In Case Designer, resolution is typically configured on the Resolution Stage (an alternate stage marked with the flag "Resolve the case"), or by inserting an Update Status automation step (Rule-Obj-Flow) in the final stage process.

The Mandatory "Resolved-" Prefix Convention

Critical CSA Rule: In Pega, a case is officially recognized as resolved by the platform engine only when its pyStatusWork property value begins with the standard prefix Resolved- (case-sensitive).

Standard Pega resolution statuses include:

• Resolved-Completed: The case successfully completed all required business steps and objectives.
• Resolved-Rejected: The case was reviewed and formally denied during an approval or evaluation step.
• Resolved-Withdrawn: The customer or initiator withdrew their request before completion.
• Resolved-Cancelled: The system or an administrative operator aborted processing.
• Resolved-Duplicate: The case was identified as a duplicate of another existing case.

System Actions Triggered by "Resolved-"

When pyStatusWork is set to a status starting with Resolved-, Pega's internal case engine automatically executes critical system housekeeping:

1. Deletes Open Assignments: Searches the Assign-Worklist and Assign-WorkBasket tables and closes out all active assignments associated with the case, ensuring no work items remain lingering in queues.
2. Halts Service Level Agreements (SLAs): Automatically terminates all active SLA timers (System-Queue-ServiceLevel), preventing false past-due escalations or notifications.
3. Releases Locks: Purges any held locks from System-Locks.
4. Records Resolution Metadata: Automatically stamps the resolution timestamp (pyResolveTimestamp), the resolving user's Operator ID (pyResolvedBy), and the resolving work group (pyResolvedByWorkgroup).
5. Excludes from Active Reporting: Excludes the case from standard operational "Work In Progress" (WIP) reports and dashboard metrics, archiving it for historical reporting.

Common Anti-Pattern: Setting pyStatusWork to custom non-prefixed values like Closed, Finished, or Archived. Doing so updates the string property on the clipboard but fails to trigger Pega's resolution automation, leaving orphan assignments active and SLA timers running indefinitely.