Designing With Claim Units (Sub-Cases) in Blueprint: One Parent, Many Specialists

[BAKEK1 (Kirsten Baker)]

Most Blueprints I see suffer from one of two extremes: too many case types or one giant case managing everything in series. There’s a better middle ground worth more airtime: the parent case + sub-cases pattern — what Pega Claims for Insurance calls FNOL → Claim File → Claim Units.

The pattern in Blueprint:

• 1. One authoritative case. A single Parent Case (Claim File) owns the end-to-end lifecycle, status, financials, and audit trail.

• 2. Sub-cases for parallel work. Break specialized adjudication into sub-cases (Claim Units) running in parallel under the parent.

• 3. Roll up, don’t fragment. Sub-case results, financials, and status roll up to the Parent Case — the business record stays coherent.

• 4. Configure, don’t multiply. Use reference data (LOB, product, region) to drive variation — not new case types.

• 5. Blueprint it up front. Model the hierarchy and roll-up rules early in Application Purpose — or delivery will reinvent them inconsistently later.

This pattern isn’t just for insurance. Anywhere you have parent/child work — orders & line items, complaints & allegations, applications & products — the same Blueprint approach applies.

The below infographic shows the full FNOL → Parent Case → Sub-Cases swimlane pattern:

• Top band: The 6 lifecycle stages (Intake → Setup & Routing → Investigation → Adjudication → Resolution → Closure).
• FNOL lane: Multi-channel intake (web/phone/email/agent) feeding the Parent Case creation.
• Parent Case (Claim File) lane: The authoritative case carrying the claim end-to-end.
• Sub-Cases (Claim Units) lane: Six specialized parallel work streams (Coverage Review, Exposure/Injury, Property Damage, SIU/Investigation, Financial Handling, Vendor/Service).
• Right rail: Key benefits (single authoritative record, parallel work, roll-up clarity, configuration over case-type sprawl, traceability).
• Bottom band: Six Blueprint design considerations for practitioners.

What’s the parent/child analog in your domain? Where do you draw the line between “new case type” and “specialization through configuration”?

[IronMan (sreeram K)]

In our domain, the parent-child equivalent is:

Client Engagement / Resource Tracking Case → Domain Work Cases such as Mobility, Immigration, Tax, KYC, and Audit

The parent case represents the authoritative engagement or resource record. It owns the overall lifecycle, client and resource context, consolidated status, key milestones, reporting information, and end-to-end audit trail.

The child cases represent independently managed workstreams. For example, an international assignment may create separate Immigration, Mobility, Tax, KYC, or Audit child cases. These workstreams can proceed in parallel, have different specialists, SLAs, documents, approvals, and outcomes, while their progress and results roll up to the parent engagement.

I draw the line between a new case type and specialization through configuration based on whether the work has an independent business lifecycle.

I would create a new case type when the work requires:

• Its own stages and resolution outcome
• Independent ownership and SLA
• Separate documents, approvals, or compliance evidence
• Parallel processing
• Independent reporting or auditability

I would use configuration when the lifecycle remains substantially the same and only the country, service, client, legal entity, tax year, risk level, or policy varies. Those differences should be driven through reference data, decision tables, business rules, and circumstance-based processing rather than multiplying case types.

[BAKEK1 (Kirsten Baker)]

Great example — the Client Engagement case with Mobility, Immigration, Tax, KYC, and Audit underneath is exactly the pattern. And “does the work have an independent business lifecycle?” is a cleaner test than the one I offered.

Thanks for adding this.

[Amey_Thombre]

Hello @BAKEK1
Thanks for providing concrete example here to explain the pattern

I’d add that the key consideration is not whether a parent-child pattern exists, but whether there is a genuine business use case that justifies it.

If the requirements call for independent specialist work streams, parallel processing, separate SLAs, ownership, or lifecycle management, then modelling these as child cases aligns with established case design best practices and should be reflected in the Blueprint.

Ultimately, this is where designer judgement and competency become critical. Blueprint can suggest and accelerate design patterns, but it still relies on experienced practitioners to apply the right case structure for the business context. A one-parent/many-child approach can be the right solution when it mirrors the real operating model, but it should always be driven by the business need rather than the technology implementation itself.

In my view, Blueprint should reinforce good case design practices, while designers remain accountable for validating that the chosen hierarchy delivers the appropriate balance of clarity, scalability, and maintainability.

[BAKEK1 (Kirsten Baker)]

Thanks — I completely agree that the parent-child pattern should be driven by a genuine business need, not just because the platform supports it.

That was the point I hoped to reinforce: Blueprint is most valuable when it helps surface these design decisions early. If the work requires independent ownership, SLAs, lifecycle, evidence, reporting, or parallel processing, a child case may be appropriate. If the variation is mainly by country, service, client, risk level, or policy, configuration is usually the better path.

Blueprint can accelerate the conversation, but practitioner judgment is still essential to ensure the case hierarchy reflects the real operating model.