Custom Dashboard Blocks

Dashboard Blocks

A dashboard is made of blocks. Each shows one thing — a number, a chart, a list, a shortcut.

Where to find it

Architect Panel → Dashboards:

• Custom Dashboard Blocks — the blocks themselves
• Dashboard Styles — the styling applied to them
• Shared Dashboard Layout — the arrangement shared across users
• BI Dashboards — the query-driven alternative

What a block can be

Several display types are available — counters, charts, lists and others — each configured against a datastore with its own criteria. A block library holds ones you have built so they can be reused rather than recreated.

A dashboard is for deciding, not for looking

The principle that separates a useful dashboard from a decorative one. Every block should answer a question somebody acts on.

The test for each: what would somebody do differently if this number changed? If there is no answer, the block is decoration — and decoration crowds out the blocks that matter.

Six or eight blocks

A dashboard people scan in a few seconds is used daily. One requiring scrolling and study is opened once and abandoned, and the good blocks on it are lost with the rest.

Put the most important thing top left

People read from there and frequently no further. If one number matters more than the others, it goes there — and if everything is equally important, the dashboard has no point of view.

A number needs a comparison

"47 open cases" means nothing on its own. Against a target, against last week, or against a threshold that changes its colour, it becomes actionable.

Where you cannot supply a comparison, ask whether the number is worth showing.

Blocks cost something to draw

Each queries data when the dashboard loads. A dashboard of twelve blocks over large datastores is twelve queries every time anybody opens it, which on a landing page is a great deal of work.

Keep criteria tight and the block count sensible — and see the performance guidance in the Business Intelligence dashboards article, which applies equally here.

Reuse from the library

Rather than rebuilding a similar block per dashboard. One definition means one place to correct it when the underlying model changes.

Permissions apply per viewer

A block shows each person what they are allowed to see, so the same dashboard legitimately shows different numbers to different people. That is correct and worth explaining before somebody reports it as a bug.

Worked example

A service desk dashboard carries six blocks: open cases against target, cases breaching today, unassigned, this week's volume against last week's, a list of the oldest five, and a shortcut to log a new one. Every block prompts an action, and the team opens it every morning.

Recommendations

• Ask what somebody would do differently for every block.
• Six to eight blocks, most important top left.
• Give every number a comparison.
• Reuse from the library rather than rebuilding.

Building a Block

A block is a display type, a datastore, some criteria, and where it sits.

Where to find it

Architect Panel → Dashboards:

• Custom Dashboard Blocks — the blocks themselves
• Dashboard Styles — the styling applied to them
• Shared Dashboard Layout — the arrangement shared across users

Architect Panel → Data:

• Datastores — the data a block draws on

Choose the display type from the question

• How many? — a counter.
• How is it changing? — a chart over time.
• How does it split? — a chart by category.
• Which ones? — a list.
• Do this — a shortcut.

Picking the display first and fitting a question to it is how dashboards end up full of charts nobody reads.

Criteria are where blocks go wrong

A block showing the wrong thing is worse than no block, because people act on it. The commonest errors are a date filter anchored to a fixed date rather than a relative one, and criteria that exclude something nobody realised.

Check the number against a report or a browse view before trusting it — once, at build time, and it will be right thereafter.

Use relative dates

"This month" rather than a fixed range, or the block quietly stops being current and nobody notices, because a number that looks plausible is not questioned.

Keep the title honest

The title is what people believe the number means. "Open cases" that actually excludes one status is a block that will mislead somebody eventually — either widen the criteria or narrow the title.

Make it clickable where you can

A number somebody cares about prompts "which ones?". A block that answers that by taking them to the underlying list is markedly more useful than one that leaves them to find it.

Test as a real viewer

Not as an administrator. Blocks respect permissions, so what you see is not what a caseworker sees — and a block that is empty or wrong for its actual audience is a block that will be ignored.

Keep it cheap

Tight criteria, and be wary of anything scanning a large datastore without a bounded filter. The block runs every time the dashboard opens, for everybody.

Worked example

A counter of cases breaching SLA today uses a relative date, is titled exactly what it counts, links through to the filtered list, and was checked against a browse view giving the same number. Viewed as a caseworker it shows their team's figure, which is what the dashboard is for.

Recommendations

• Pick the display from the question.
• Always use relative dates.
• Verify the number against a report at build time.
• Test as a real viewer, not an administrator.