Childcases is taking another Case ID parent

Case‑6347

Case‑6347 initially displayed the customer name “Client A.”
Subsequently, after Case‑6261 was returned to the executive, it was identified that the customer name in Case‑6347 was updated to “Client B,” even though no direct manual update was performed on this case.

Additionally, after this change, Case‑6347 could no longer be accessed because it was incorrectly assigned with the parent ID corresponding to Case‑6261, resulting in an incorrect relationship between the two cases.


Case‑6261

Case‑6261 corresponds to the customer “Client B.”
This case was sent to the executive and did not present any issues during its processing or closure.

Could you please redact your question. It is not readable in current state. Thanks.

Question:
How could it have happened that child case 6347 changed its parent case to OH00006755, when it was previously linked to parent case OH00006842?
No manual update was performed on case 6347, yet it appears to have automatically reassigned its parent, which also caused data inconsistencies. Has anyone experienced a similar issue or can provide insight into what might trigger this behavior?

Can you please provide reproduction steps? Otherwise it is very difficult to guess what happened? Do you have some processing with Activities being done?

We never had this issue with Pega OOTB Workflow.

Could you please confirm if there are data fix utility runs on those cases? or Job schedulers running behind the scenes to update these information(could be flaw in the logic)? How about the pxCoveredInskey for the parent and pxCoverInsKey for child? Is that updated with wrong linking?

Case 6347 was generated as a copy of Case 5000, while Case 6261 was created as a new case (without direct inheritance from another case).


Current state of relationships (cover properties)

  • Case 6347 currently has pxCoverInsKey = OH00006755.

  • Case 6261 has pxCoverInsKey = OH00006755.

  • The parent case OH00006755 contains in pxCoveredInsKeys a reference to Case 6261.

  • There is no consistent evidence of Case 6347 being included in this list.


Operational considerations

No manual utility executions were identified (e.g., data correction activities).