Shared Services Case Type Explosion

I would not collapse all 14 into one case type. That would reduce duplication but force unrelated lifecycles, data, and reporting into one case type, recreating the maintenance problem in a different form.

Proposed structure: an abstract parent case type, ServiceRequest, with common properties and processes: requester, cost center, attachments, approval, notification, and audit. Then child case types for HR, Finance, and IT requests, or for groups of requests that truly share a lifecycle. Case type inheritance lets the children inherit the common approval and notification processes while overriding only what differs.

Trade-offs:

• One mega case type is simpler only if the lifecycles and data are genuinely identical. Here HR has regulatory approval, finance does not, and IT has a security review, so a single lifecycle would need many conditional branches.
• Parent and child case types add some design complexity, but a change to the common approval policy is made once in the parent and inherited.
• Reporting improves because the parent defines common requester and cost center properties, and children inherit them.
• If two request types are identical in lifecycle and data, they can share one child case type or even one case type. Do not create a child just for organizational naming.

The judgement call is to consolidate the shared behaviour, not every request.

Move approval into the parent ServiceRequest case type as a common process, then parameterize the differences.

Design:

• Define the approval flow once in the parent, including the approval assignment, notification, escalation, and audit.
• Use a decision table or when rules to set approver routing based on request type, amount, cost center, and risk. The policy lives in one decision logic, not in 14 copies.
• Add the HR regulatory approval as an optional process in the HR child case type or as an additional approval stage that the parent does not run for finance. Add the IT security review as an optional process in the IT child. Do not put both in the parent and switch them off with complex conditions unless the conditions are stable.
• Centralize correspondence and notification templates in the parent so wording changes are made once.
• Use inheritance testing: change the parent approval and run regression cases for HR, finance, and IT to prove the override still behaves correctly.

The key is to distinguish common policy from conditional policy. Common steps stay in the parent; genuinely different regulatory or security steps are optional processes in the child case type. That gives one place to change the common policy without forcing every request through every review.

The error is a symptom of long-running approval work sharing the same case lock as the requester's attachment work. Pega locks the case when an assignment that can update the case is opened, so a second user cannot open another update assignment on the same case.

Options:

• Best fit: move approval into a child Approval case. The child has its own lock and SLA, and the parent can continue to accept attachments. Use a case dependency only where the parent must wait for the approval outcome before closure.
• If approval must stay in the parent, shorten the lock window. Do not leave an approval assignment open for days in a way that holds the case. Use an approval queue and open the assignment only when the approver is actively working, or configure optimistic locking so the lock is acquired at submit rather than at open. Handle the conflict with a clear message.
• Separate attachment upload from the approval case if attachments are the only conflict. The requester can upload to the parent while approval runs in the child.
• Do not use detached assignments as the default fix; they can hide data-consistency problems.

Given that approval can take days and the requester needs to upload supporting documents, the child Approval case is the cleanest design. It removes the lock contention and still preserves audit and dependency where needed.