3.2 Child Cases, Data Propagation & Wait Steps

3.2 Child Cases, Data Propagation & Wait Steps

CSA Exam Focus: Pega applications structure complex enterprise work using hierarchical case relationships. Certified System Architects must know when to implement a Child Case versus a Sub-process or a Separate Case Type, how to automate child case creation and data propagation, how to pause parent cases using Timer and Case Dependency Wait steps, and how to maintain lifecycle integrity when resolving parent cases.

---

Case Hierarchies: Top-Level Cases vs. Child Cases

In Pega Case Management, a Top-Level Case represents a primary business transaction initiated directly by a customer or internal user (e.g., Auto Accident Claim, Mortgage Application, Candidate Hiring). A Child Case (also known as a sub-case) represents a distinct, subordinate unit of work that must be completed to fulfill part of the parent case's broader business objective.

Child cases are fundamentally different from simple sub-processes. A child case is an independent case instance with its own:

• Unique Case Identifier (e.g., Parent is C-1001, Child is C-1001-C1 or INSP-502).
• Dedicated Case Lifecycle (stages, processes, steps, and alternate stages).
• Distinct Case Status (pyStatusWork).
• Independent Service Level Agreements (SLAs) and urgency calculations.
• Separate Assignment Routing, audit trails (History- records), and security access controls.

When to Use a Child Case vs. Sub-process vs. Separate Case Type

Choosing the correct design pattern is a frequent CSA exam scenario. Use the following architectural criteria:

Decision Rule: Use a Sub-process if the work is simple, completed quickly by the same team, and shares the parent case's status and SLA. Use a Child Case if the work represents an independent transaction requiring its own stages, different assignment routing, separate SLAs, or multiple instances (e.g., conducting 3 separate property inspections under one commercial loan). Use a Separate Top-Level Case if the two transactions have loosely coupled lifecycles and can exist completely independently of one another.

---

Creating and Instantiating Child Cases

Pega provides low-code tools in Case Designer (App Studio and Dev Studio) to manage child case lifecycles.

Instantiation Modes

Under the Settings tab of the parent Case Type, or by adding a Create Case automation step directly to a stage process, architects can configure three instantiation mechanisms:

1. Automatic Instantiation upon Stage Entry: The child case is instantiated automatically by the system as soon as the parent case enters a designated stage. For example, entering the "Underwriting" stage automatically generates an Applicant Background Check child case.
2. Conditional Instantiation: The child case is created automatically only when a specified When condition rule evaluates to true. For example, an insurance claim instantiates a Special Investigations Unit (SIU) Fraud Review child case only when .EstimatedLossAmount > 100000 or .FraudRiskScore >= 75.
3. Manual / User-Instantiated: The child case is created on demand by an operator or case worker through the User Portal's Actions menu or an Add Case button. For example, a customer service representative handling a banking dispute manually creates an Expedited Card Replacement child case if the cardholder mentions their card was stolen while traveling.

---

Data Propagation: Property Mapping at Creation Time

When a child case is instantiated, it frequently requires context from the parent case, such as customer contact details, claim identifiers, account numbers, or policy limits. Pega facilitates this transfer through Data Propagation.

Configuring Data Propagation

Data propagation is configured on the Settings > Data Propagation panel of the parent Case Type in Case Designer. The architect defines property mapping pairs:

• Source Property (Parent): .Customer.FullName, .PolicyNumber, .IncidentDate
• Target Property (Child): .Customer.FullName, .PolicyNumber, .LossDate

Property mapping supports single-value scalars, value lists, and entire embedded pages or page lists. When mapping an embedded page (e.g., parent .BillingAddress to child .BillingAddress), Pega copies all subordinate properties in that page structure.

Critical Architectural Principle: Snapshot vs. Ongoing Synchronization

Exam Trap: Data propagation is strictly a one-time snapshot executed at the moment the child case is created. It copies values from the parent to the child during instantiation.

Data propagation does not maintain active, bidirectional synchronization. If a customer updates their phone number or address on the parent case two days after child case creation, the child case does not automatically receive the updated data. Similarly, changes made within the child case do not automatically flow back up to the parent.

If ongoing synchronization is required, architects must implement explicit synchronization logic:

• Using Data Pages with an external System of Record key so both cases reference live data.
• Triggering a Data Transform or Declare Trigger rule on the parent case when critical properties change, iterating over child cases (pxCoveredInsKeys) to update their properties.
• Passing updated values back upon child case resolution through a custom post-processing data transform.

---

The Wait Step: Pausing Case Execution

When a parent case instantiates one or more child cases, the parent frequently reaches a point where it cannot proceed until those child cases have finished their work. Pega solves this using the Wait automation step (Rule-Obj-Flow).

The Wait step pauses case processing and releases the thread until a specified condition is satisfied. Pega provides two primary types of Wait steps:

1. Timer-Based Wait

A Timer-based wait halts case processing for a specific duration or until a calendar milestone arrives:

• Wait for a specific duration: Pauses execution for a defined time interval (e.g., 48 hours, 5 business days). Pega calculates the expiration timestamp using the application's business calendar.
• Wait until target date/time property: Pauses execution until the timestamp stored in a case property (e.g., .CourtHearingDate or .PolicyRenewalDate) is reached.

System Mechanics: When a timer-based wait executes, Pega puts the assignment into the ProblemWork or internal timer queue and creates a scheduled task managed by Pega background Queue Processors (pzStandardProcessor). When the timer expires, the queue processor awakens the case, re-acquires the lock, and resumes execution at the next shape.

2. Case Dependency Wait

A Case Dependency wait pauses the parent case until one or more other cases achieve a designated status.

Architects configure three primary parameters for a Case Dependency wait:

1. Case Type: The specific child case type (or sibling case type) to evaluate (e.g., Vehicle-Inspection).
2. Target Status: The required case status, typically a resolved state such as Resolved-Completed or Resolved-Approved.
3. Scope / Quantity Condition:
   • All cases of this type: The parent remains paused until every child case of that type reaches the target status.
   • Any case of this type: The parent resumes as soon as at least one child case of that type reaches the target status.

Furthermore, Pega allows cases to wait on sibling or related top-level cases by configuring property-matching criteria (e.g., wait for a case where .AccountID matches the parent's .AccountID).

---

Resolving Parent Cases with Open Child Cases: Guardrails & Best Practices

In Pega enterprise design, maintaining lifecycle integrity between parent and child cases is critical.

The Orphan Child Case Anti-Pattern

If a parent case is resolved while child cases remain open and active, those child cases become orphans. Orphan child cases present severe business and operational risks:

• Child case SLAs continue ticking, escalating urgency, and triggering past-due notifications to managers for work whose parent transaction has already concluded.
• Operators waste time working assignments for child cases whose parent objective was cancelled or settled.
• Operational dashboards and compliance audits report inaccurate volumes of active work in progress.

Best Practices for Parent-Child Lifecycle Governance

1. Enforce Case Dependency Wait Steps: Place a Case Dependency Wait step in the stage immediately preceding parent resolution, configured to wait for All child cases to reach Resolved-Completed or Resolved-Cancelled.
2. Automate Cascading Cancellation: If a parent case is withdrawn or rejected (moving to an alternate stage like Cancellation), configure an automated utility step or sub-flow that iterates through pxCoveredInsKeys (the list of child case handles) and automatically updates each open child case status to Resolved-Withdrawn or Resolved-Cancelled, closing out all active assignments.
3. Validation Guardrails: Before allowing an operator to execute a manual resolution action on a parent case, configure a validation rule (Rule-Obj-Validate) that checks whether any covered child cases in the clipboard page .pxCovered have a status that does not start with Resolved-.