We would like Chorus BPM to support richer, multi-level parent-child relationships between work items, allowing a business hierarchy to be represented directly within the Chorus work model.
The current Chorus object model supports explicit parent-child relationships, including a case containing multiple transactions/tasks. However, the documented relationship rules do not allow a transaction/task to be the child of another transaction/task.
For more complex business processes, we would like to extend this concept beyond a single task level so that a hierarchy such as the following can be represented natively:
The intention is that each level represents an explicit relationship between independently processable work items, rather than representing the hierarchy indirectly through naming conventions, reference fields, or other metadata.
Desired capability
Ideally, Chorus would support:
- Multiple levels of parent-child relationships between processable work items.
- Explicit relationships that can be navigated and understood by Chorus rather than inferred from work-item metadata.
- Parent work that can coordinate processing based on the state or completion of its child work.
- Child completion that can signal or otherwise participate in progression of its parent, supporting event-driven orchestration.
- Multiple branches of work executing independently or in parallel beneath the same parent.
- Relationship information being available for operational visibility, troubleshooting and reporting.
The objective is not simply parallel processing. The requirement is to maintain the business relationship between parallel work items as part of the Chorus work model.
Business example
A Disability Claims process provides a useful example.
A single claim may involve multiple products that need to be processed independently and potentially in parallel. Each product may then have its own downstream activities, such as assessments, payments or work associated with individual payees.
Conceptually:
In this type of process, the hierarchy is meaningful business information. We would therefore like the workflow engine to understand and maintain these relationships directly.
Where relationships must instead be reconstructed using naming conventions, reference fields or custom linking attributes, additional application logic is required to determine which work items belong together and when the related work has completed. This makes orchestration, reporting, troubleshooting and future extension more complex.
Business value
Native multi-level work-item relationships would allow Chorus to model complex business processes more closely to their real-world structure while preserving independent and parallel processing.
It would also support a cleaner orchestration model in which relationships are explicit and process progression can be driven by the state of related work, rather than requiring consumers to reconstruct those relationships through conventions and queries.
This would strengthen Chorus as a workflow orchestration platform for use cases where a single case can contain multiple levels of independently managed but related work.
