List Mode and Row Listings
Not every question is an aggregate. "Which repairs are overdue?" wants rows, not a count — and list mode makes a row listing a first-class thing the BI subsystem can hold, chart and place on a dashboard.
Where to find it
Architect Panel → Data:
- Query Builder — where a query is switched to list mode
Architect Panel → Dashboards:
- BI Dashboards — where a listing is placed alongside charts
Why this needed to exist
Before list mode, a dashboard could tell you there were fourteen overdue repairs but not which ones. The answer was to build a separate browse view with its own filters — which then drifted from the dashboard's definition, so the count and the list disagreed and nobody knew which to believe.
List mode uses the same query definition for both. If the dashboard says fourteen, the listing has fourteen rows in it, by construction.
When to use rows rather than a total
- Work queues — the point is to act on individual items.
- Exceptions — a count of exceptions is less useful than the exceptions.
- Anything under about twenty rows where a person will want to see them all anyway.
Use an aggregate when the number itself is the point, and a listing when the next action is on a row.
Worked example — an exceptions listing
A finance team wanted "invoices over 60 days". The count alone told them there were 23 and nothing else. In list mode the same query returns the 23 rows with customer, value, age and owner — sorted oldest first — and the team works straight down it. The dashboard figure and the listing cannot disagree, because they are one query.
Keep listings short
A listing of two thousand rows on a dashboard is a performance problem and an unreadable screen. Filter it to what is actionable — overdue, unallocated, awaiting approval — and let the full set live in a browse view somebody opens deliberately.
Choose the columns for the decision
Show what somebody needs to decide what to do, not everything the datastore holds. For an overdue repairs listing that is usually the reference, the address, how overdue, and who owns it. The tenancy history is not a decision input at that moment.
Worked example
An operations dashboard carries three blocks: a trend chart of repairs raised, a figure for the current backlog, and a listing of everything more than five days overdue with its patch and owner. The listing is the same query as the figure, in list mode, so the two always agree — and the supervisor works straight from the listing rather than exporting it.
Recommendations
- One definition, two presentations. Never build a separate view to accompany a count.
- Cap the rows and sort by what matters most.
- Include the owner column on anything actionable — a list nobody is named on is a list nobody does.