BI Dashboards

Building a Dashboard

A dashboard collects saved queries into one screen.

Where to find it

Architect Panel → Dashboards:

• BI Dashboards — create and edit dashboards
• Custom Dashboard Blocks — blocks beyond the standard chart types
• Dashboard Styles — how they look
• Shared Dashboard Layout — a layout used across a team

Decide what it is for

The best dashboards answer one question: is anything wrong today. Overdue obligations, unallocated cases, stock below minimum, an unprocessed feed inbox, maintenance due, aged debt.

Analysis is a different job and belongs in a report somebody opens deliberately. Mixing the two produces a screen that is neither — too detailed to scan and too shallow to investigate with.

Keep it short

A dashboard of twenty charts is one nobody reads. Its real cost is not the wasted effort; it is that the two figures that genuinely mattered were on it and got ignored among the other eighteen.

Six to eight blocks is usually the practical limit for something scanned daily.

Choose the right block

• Trends over time — a line, with gap fill on.
• Comparisons between categories — a bar, sorted, top-N.
• A single important number — a figure, not a chart of one thing.
• Things to act on — a listing in list mode.

A pie chart with eleven segments communicates less than the list it was made from.

Shared layouts

Where a team should all see the same thing, use a Shared Dashboard Layout rather than each person building their own. One change updates everyone, and it prevents the situation where two people in a meeting are looking at differently-configured versions of the same dashboard and disagreeing about reality.

Styles

Dashboard Styles keeps presentation consistent. Use colour to mean something — red for breach, amber for approaching — and use it sparingly. A dashboard where everything is coloured conveys nothing.

Worked example

A casework team's dashboard has six blocks: cases opened this week (figure), open by stage (bar), obligations due in seven days (figure), breached this month (figure, red when above zero), unallocated (listing), and oldest ten open cases (listing). It is scanned every morning in five minutes, and every block has a next action attached to it.

Review what is actually used

Dashboards accumulate. Once or twice a year, find out which are still opened and retire the rest. A stale dashboard showing a metric nobody tracks any more is worse than none, because somebody will eventually believe it.

Recommendations

• One question per dashboard.
• Every block should imply an action. If it does not, it belongs in a report.
• Use shared layouts for teams.
• Retire dashboards nobody opens.

Keeping Dashboards Fast

A dashboard runs every query on it. Slow dashboards get abandoned, so this deserves attention before people stop opening them.

Where to find it

Architect Panel → Dashboards:

• BI Dashboards — the dashboard and its blocks

Architect Panel → Data:

• Query Builder — where the underlying queries are tuned

Caching, and what it costs you

Results are cached, so a dashboard several people open in a morning runs its queries once rather than once each. The first load after the underlying data changes is the slow one; subsequent loads are not.

The trade is freshness. Decide how current each figure genuinely needs to be — an operational queue count wants to be live; a monthly revenue trend does not, and pretending it does costs you performance for no benefit.

Common causes of slowness

• Too wide a period. Most dashboard questions are about now. Three years of history to show this week's figure is wasted work on every load.
• Too many blocks. Every block is a query. Ten is a dashboard; thirty is a report that happens to have charts.
• High-cardinality groupings. Grouping by something with thousands of distinct values produces a result nobody can read and takes time to produce. Use top-N.
• Missing indexes. Dates and the columns you filter on should be indexed. This is the single highest-value fix and the one most often overlooked.
• Unbounded listings. A list-mode block with no row cap will happily try to render everything.

Where the data is genuinely large

Aggregating a long movement or journal history is expensive however well it is written. Where a figure is needed often and changes rarely, schedule it and deliver the result rather than computing it live every time somebody looks.

Test at the size it will be

A dashboard built against six months of data behaves differently against six years. If you are early in a system's life, run the query against realistic volumes — or against a copy with generated data — before promising it to anyone.

Worked example

A finance dashboard took eleven seconds to load. Two changes fixed it: the revenue trend was narrowed from five years to eighteen months, and an index was added on the journal date column. It now loads in under a second, and nobody has asked for the missing three years.

Recommendations

• Index dates and filter columns first. Usually the biggest single win.
• Narrow periods aggressively. Add history back only if somebody asks.
• Cap every listing.
• Move genuinely heavy work to a schedule.