Understanding Where CHILD_INCIDENT_QUERY_FILTER Comes From (Extension Point Deep Dive)

[Matthew_13]

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.

12/25 - 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:

1. Confirm whether an extension point is driving the logic

2. Review existing implementations that may already affect the query

3. 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

[ZebaT · Accepted solution]

@Matthew_13 

Why are you asking questions and self marking your reply as solution? Almost all your post are doing same thing.?  kindly refrain doing it, it creates bad impression on your profile and community