I’m designing a case structure where we have parent cases spawning multiple child cases with complex dependencies. We’re running into challenges with parent-child synchronization - specifically when child cases complete, the parent needs to update its status, but we’re seeing inconsistent case closure behavior. Additionally, SLA timers on the parent seem to conflict with child case SLAs, and data propagation between parent and children isn’t always reliable. I’d like to hear how others have architected similar scenarios. What patterns have worked well for maintaining case hierarchy integrity while ensuring proper data flow and SLA coordination?
For parent-child synchronization, we use case status propagation rules with explicit wait conditions. The parent waits for all children to reach resolved status before proceeding. However, you need to handle edge cases like cancelled child cases or exceptions. We implemented custom validation to check child case states before allowing parent closure, which solved the inconsistent closure issues.
Consider using case dependencies rather than pure parent-child if you need bidirectional relationships. Dependencies give you more flexibility in how cases relate to each other and can simplify your synchronization logic. We switched from strict parent-child to a dependency model and it resolved many of our coordination issues.
The SLA approach makes sense. Are you using goal and deadline SLAs on the parent with just milestones on children? How do you handle situations where a child case is delayed - does it automatically impact the parent SLA?
After working with several complex case hierarchies, here’s what I’ve found most effective across all three areas:
Parent-Child Synchronization: Implement explicit synchronization points rather than relying on automatic propagation. Use a combination of wait shapes in the parent case flow (waiting for child case resolution) and case status update automation. The parent should have a dedicated subprocess that monitors child case completion - triggered by child status changes via case dependencies. This ensures the parent always has an accurate view of child states before making closure decisions. Include error handling for scenarios where child cases are cancelled or stuck.
SLA Management: Structure your SLAs hierarchically with clear ownership. The parent case owns the business-level SLA (goal and deadline), while child cases use milestone tracking rather than independent SLAs. Configure the parent SLA to account for child case duration by setting realistic goals based on expected child completion times. If a child is delayed, it should trigger a milestone violation that surfaces to the parent, but doesn’t create competing SLA timers. Use SLA propagation rules to escalate child delays to parent case stakeholders automatically.
Data Propagation: Establish a clear data flow architecture. At child case creation, use CaseCopyData to pass required context from parent to child. Define a specific property set for this initial copy - don’t copy everything. When children complete, implement a controlled data-back pattern: the child case triggers a parent update activity that selectively pulls back only changed or calculated data. Use declarative expressions on the parent to aggregate child case data (counts, statuses, calculated values) rather than pushing updates from multiple children. This declarative approach prevents race conditions and ensures consistency.
The combination of explicit synchronization, hierarchical SLA ownership, and controlled data propagation creates a stable, maintainable case architecture that scales well as complexity grows.
One pattern that’s worked well: implement a parent case update subprocess that triggers on child case status changes. Use declarative processing to keep parent data synchronized rather than trying to push updates from children. This inverts the control and gives you better consistency.
We implemented a similar structure for a claims processing system. The key was establishing clear ownership rules - the parent should own the overall SLA, while child cases have internal milestones rather than independent SLAs. This prevents the timer conflicts you’re experiencing.
For data propagation, we leverage the CaseCopyData activity with specific property mapping. Define exactly which properties flow from parent to child at creation, and which flow back on child resolution. Don’t rely on automatic propagation - it’s too unpredictable with complex data structures. We maintain a data synchronization matrix that documents every property flow direction and trigger point.