Parent vs. Child Cases

Blueprint and App Design
,
1

One of my customers recently asked about Pega parent/child case relationships and when something should be modeled as a child case versus simply remaining part of the parent case workflow. I thought I’d share the guidance I provided since it’s a question that comes up frequently.

Parent Case Represents the primary business objective or desired outcome. It owns the overall process, customer context, and end-to-end resolution.

Child Case Represents a discrete unit of work required to support the parent’s objective. Child cases can run independently, be assigned to different teams, maintain their own SLAs, audit trails, and outcomes, while still contributing to the overall resolution of the parent case.

One of the strengths of Pega’s case architecture is that each child case remains a fully functional case of its own while still inheriting context from the parent when appropriate.

When Should You Create a Child Case?

While there’s no single right answer, I generally use three guiding principles:

  • The work needs to be tracked independently: If the work requires its own SLA, status, ownership, reporting, or resolution, it’s often a good candidate for a child case. Example: In a customer onboarding process, a Compliance Review could be modeled as a child case since it has its own lifecycle, approvals, and tracking requirements.

  • The capability can be reused elsewhere: If the same business function might be invoked from multiple processes, making it a child case promotes reuse and consistency. Example: A Document Verification case may be used during customer onboarding, account updates, and loan applications.

  • The process depends on completion of another process: In the parent case, you can define conditions that require all or some of child cases to be complete before the case moves forward. Example: A Risk Assessment child case must be resolved before a financial product application can move to final approval.

A Simple Rule of Thumb

When evaluating whether something should be a child case, ask:

  1. Does it need its own SLA, ownership, or reporting?
  2. Could this capability be reused by another process in the future?
  3. Does the parent case need to wait for it to complete before moving forward?

If the answer to any of these is yes, it’s likely worth considering a child case rather than another stage or step within the parent case.

Curious how others approach this decision. What additional factors or design patterns do you use when determining whether work should become a child case?

2

Great stuff @latit

I’d also add to The work needs to be tracked independently, and say The work needs to be tracked independently.

Parallel processing and multiple assignments on case for different tasks to different people is ok BUT if you expect people to work at the same time then they would need different cases so they don’t clash.

Thanks again for your insights!

3

In addition to what you said I would also suggest a child case when there are multiple tasks running in parallel assigned to different users and I need to ensure that each one can make their updates without having to worry about having the case locked by another user

4

Love the write-up, Tanya. Wanted to add a +1 to the “Could this capability be reused by another process in the future?” point.

I was working with a client where they had a process for uploading and reviewing documents in every onboarding case. Originally they wanted to just make that its own stage, but after conversations, it became clear that so much of their business required a diligent, orchestrated, governed process for taking in and reviewing documentation. They also planned to make that a process that could include Agentic capabilities. After review and conversation, we realized together that standing that up as a separate child case would lead to their ability to easily reuse it across new cases we had planned in the future. Great post! Cheers!