BI Dashboards

Building a Dashboard

A dashboard collects saved questions 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, aged debt. Things somebody will act on.

Analysis is a different job and belongs in a report somebody opens deliberately. Mixing the two produces a screen that is neither.

Keep it short

A dashboard of twenty charts is one nobody reads, and its real cost is that the two figures that mattered were on it and were ignored. If everything is on the dashboard, nothing is.

Choose the right chart

Trends over time as a line, comparisons between categories as a bar, and a single important number as a number. 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 layout rather than each person building their own. It means one change updates everyone, and it stops the situation where two people in a meeting are looking at differently-configured versions of the same dashboard.

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.

Keeping Dashboards Fast

A dashboard runs every question on it. Slow dashboards get abandoned, so this is worth attention.

Where to find it

Architect Panel → Dashboards:

• BI Dashboards — the dashboard and its blocks

Caching

Results are cached, so a dashboard several people open in a morning runs its queries once rather than once each. The first load after 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.

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.
• Too many blocks — every block is a query. Ten is a dashboard; thirty is a report.
• High-cardinality groupings — grouping by something with thousands of distinct values produces a result nobody can read and takes time to produce.
• Missing indexes — dates and the columns you filter on should be indexed.

Where the data is large

Aggregating a long movement or journal history is genuinely expensive. Where a figure is needed often and changes rarely, consider a scheduled report delivered by email rather than a live block somebody waits for.

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, check the query against realistic volumes before promising it to anyone.