I often get asked what the checkbox "Apply to all tables in hierarchy" does to Interactive Filters. There seem to be some misconceptions. Let's take a few minutes to review some examples of what it really does.

The docs tell us this:

"If the source table is incident, then the interactive filter applies to incident; its parent table, task; and to its sibling tables, problem and change."

Let's go through a few scenarios to really understand this.

I created this dashboard with a few key objects on it:

• Four Interactive Filters to show various configurations
• Three Single Score Reports to demonstrate what happens when the filters are applied
• The Debug Filter to show us what the Interactive Filters are sending to the reports

Interactive Filters

Let's walk through the different Interactive Filters we have setup. Here is a quick summary of the differences.

Name	Hierarchy Checked	Mapped to
Assignment Group - Incident	No	Incident
Assignment Group - Task & Incident	No	Task & Incident
Assignment Group - Task	No	Task
Assignment Group - Incident w/ Hierarchy	Yes	Incident

Filter Definition

The filters are all identically configured on the sys_user_group table with different table mappings as noted above. The "Apply to all tables in hierarchy" option is only checked on "Assignment Group - Incident w/ Hierarchy".

It is only mapped to the incident table.

Test Data & Reports

We have three single score reports. Each one is a count of records in the Incident, Tasks where the task type is Incident, and Problem table respectively. [As a reminder, Incident and Problem both extend Task].

We are reporting on the Incidents and Problems with the assignment group of "Software". Here is the results we are looking for:

Filters in Action

Let's look at the results when we apply each filter individually. We'll select "Software" as the Assignment Group for each filter and see what happens to the reports on Incident, Task, and Problem.

Mapped to Incident - No Hierarchy

Only the report on Incident changed. We see in the debug filter that the incident table is the only table being filtered.

Mapped to Task & Incident - No Hierarchy

All three reports changed because they are all either task or incident. We see in the debug filter, both incident and task are filtered.

Important Note about Multiple Mappings

For the report on the incident table, we get the same answer because we mapped the same field for incident and task. If we mapped a different field for incident and task (this can happen if we have caller mapped for incident and assigned to for task), we can end up with no records returned because we must match the filters for both incident and task. The mappings are AND'd not OR'd.

For instance, if we mapped caller on incident and parent.caller on incident_task we may get collisions since they both extend task.

Mapped to Task - No Hierarchy

All three reports changed because they are all either task or extended from task. We see in the debug filter, just task is filtered.

Mapped to Incident - With Hierarchy

All three reports changed because they are all in the same hierarchy as incident (task). We see in the debug filter, just incident is filtered with the extra option to apply to the entire hierarchy.

Conclusion

Looking through these examples, we can draw a few conclusions:

• When creating a mapping, choose the lowest level class possible so we don't have to create a mapping for every extension.
• "Apply to all tables in hierarchy" is useful in some edge cases, but not needed in most cases.
• We need to be aware not to create mismatching mappings for tables in the same hierarchy.