Understanding Where CHILD_INCIDENT_QUERY_FILTER Comes From (Extension Point Deep Dive)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
Problem:
While working with parent–child incident relationships, I couldn’t find where CHILD_INCIDENT_QUERY_FILTER was being defined or applied. It wasn’t obvious from the UI, business rules, or scripts, which made troubleshooting confusing.
Accepted Solution:
The key detail I discovered is that CHILD_INCIDENT_QUERY_FILTER is resolved through an extension point, not a hardcoded query.
Specifically:
The filter is determined at runtime
The extension point implementation controls how child incidents are queried
This explains why behavior can vary between instances or configurations, even when everything looks OOTB
Once I identified the extension point and reviewed its implementation, the source of the filter became clear and the behavior made sense.
Why this matters
If you’re:
Customizing parent/child incident behavior
Investigating missing or unexpected child incidents
Attempting to override OOTB incident logic
Checking the relevant extension point should be one of the first steps. Otherwise, it’s easy to spend time debugging scripts or rules that aren’t actually involved.
Takeaway
Before modifying incident relationships:
Confirm whether an extension point is driving the logic
Review existing implementations that may already affect the query
Validate the filter at runtime instead of assuming static behavior
*Please give me a thumbs up Helpful if this was a good read. Thanks Kindly
