Enhanced Widget Connections in Dashboards

The request behind this idea is to have additional control over how dashboard visualizations respond to each other via widget connections. It is understood that additional connections can be created to group respective visualizations together but this does not account for all scenarios.

Let's use an example from the Education industry where we have the following:

• A Student dimension table

• An Enrolment fact table which records which school year, school and grade a student is enrolled in

• A Marks fact table which records the marks a student receives for various subjects

• An Attendance fact table which records which the date a student was absent

• We want to build a Student 360° dashboard which provides teachers with the information they need for a student

• On the left hand side of the dashboard is a List visualization from the Enrolment namespace (star schema grouping) which lists all of the students

• On the top right hand side is a visualization (doesn't matter which one) which displays the student's marks

• On the bottom right hand side is a visualization (doesn't matter which one) which displays the Attendance data

Current Cognos Functionality

What's happening today (11.2) is that the list of students on the left hand side is being filtered down to those that have Marks data AND Attendance data. This is a problem because a teacher won't have the ability to select a student that has perfect attendance. This is due to the fact that the Student List is being filtered by the Marks data AND Attendance data.

Note that moving the Student list from the left hand side of the dashboard to a filter at the top resolves the issue. However, this isn't an elegant user experience.

Enhancement

In this scenario, we want the Student List to be used to filter the two visualizations. We do not want the list of student to be limited to those that have records from all fact tables. It would be nice to be able to control this through widget connections or identifying that an outer join should be performed from the Student table.

This idea / enhancement would benefit any organization that has multi-fact queries in their Framework Manager project.