Case To Case Associations/Relationships

[StephenOTT]

Re-introduction of Case to Case Associations/Relationships:

• Child
• Related/Similar
• Merged

---

Definitions:

Similar Cases (Related Cases): Cases that should all remain open until user choses to close them. This is a Sibling relationship not a Parent-Child. Example would be multiple noise complaints about a Festival. Each request must remain open but they are Related/Similar. Similar cases do not automatically close when one of the cases in the sibling relationship is closed, and no information is shared automatically between the similar cases (Shared information must be defined as a Business Process Level where the process propagates copies of the data across the cases). Any changes to the cases in the sibling relationship will need to be applied as a manual Bulk Operation or scripted Bulk operation that is activated by a user with the appropriate permissions.
We should create “Real Life Events” that cases can be grouped against for similar cases so there is a master object. Example master object would be Canada Day or Festival.

Merged Cases: Cases should be merged when there is duplication from a single staff member or citizen. When a case is merged a case is chosen as the Parent case (likely the first case opened), and all other cases (merged cases) are closed and have a status as “Merged” or something like that with a Merged association. There should always be a link on the case page and a message explaining what is going on and why. The parent case will have History showing the merged cases.

Child Cases: Cases that have a Parent-Child relationship. A Case is chosen to be a parent (likely the first case created) and every other case is a child. Child Cases remain open, but in many situations, the parent case is the only case sent to the Back-Office to be resolved/fulfilled. When a Parent case is closed, the child cases are automatically closed. The messages and statuses that are applied to the parent case are automatically applied to the children cases. An example of this would be a pothole request. Every request for Pothole A would be created as a child case, and only the original pothole request will be sent to the Back-Office to be resolved. Back office sometimes uses the number of cases they receive about an issue as an indicator for the importance/severity of the issue; therefore there should be some sort of Notification and API call that can be used to determine “popularity” of an issue so that if a issue becomes increasing popular / more complaints are being made about it, the back-office should receive this information/indicator so they can act appropriately.

---

Actions that occur because of a relationship is being handled by BPMN processes