Dashboards and reports

Build a custom dashboard

Build a chart, put it on a board, and freeze the result when you need a number that stops moving.

Build your own when the prepared views do not answer the question, not before. A board nobody opens is worse than no board, and every custom chart is a definition somebody now has to maintain.

How this will work. Analytics Studio is planned and not yet on your tenant. This page describes the dashboard and chart builder as designed. A chart is always built against a dataset; know which dataset holds the field you want, and know what counts as an order if the chart involves revenue.

Create the dashboard

A new dashboard is created immediately and opens empty. Rename it to the question it answers: Innendienst — weekly account review beats Sales KPIs. The plan includes a bundled sample dashboard you can clone rather than starting from nothing, and cloning any existing board to branch from it.

Build a widget

A widget is one chart bound to one saved query. Widgets live on dashboards; there are no standalone saved charts, so building one and adding it to a board is a single flow. The decisions, in order:

  1. Pick the dataset. Its fields and their types are listed beside it.
  2. Give the widget a title. This is what the reader sees. Make it a statement with the definition in it: "Net revenue (placed, excl. VAT)".
  3. Choose the chart type: KPI, line, bar, donut or table.
  4. Define the metric. An aggregation (count, count distinct, sum, average, minimum, maximum) and, for everything except a plain count, the column it applies to. Bar and line charts accept more than one metric.
  5. Add the dimension the chart type needs. A line needs a time field and a grain (day, week, month, quarter, year). Bar and donut need a group-by column. A table needs the columns to show.
  6. Optionally break down by a second dimension (bar and line only), turning one series into one per value.
  7. Add filters if the chart should only cover part of the data.
  8. Set a row limit, then check the live preview and add the widget to the board.
Advanced SQL. The design includes a SQL mode for a query the controls cannot express: read-only SELECT statements, rendered as a table. Use it for the one query a year that needs it, not as the default. A chart built in the controls stays readable to whoever inherits it.

Live and frozen

A dashboard is designed to have two modes.

Live re-runs every widget's query. This is the working mode, and the number can change between two people opening it four minutes apart.

Report shows a snapshot: the result of every widget on the board, frozen with a timestamp. This is what you want for anything that gets discussed: a month-end review, a board pack, a figure quoted in a meeting. A live dashboard in a meeting is an argument waiting to happen.

Snapshots are taken by hand. Plan on no scheduled or automatic snapshotting.

What not to expect in the first release

Worth knowing so you do not design a process around it:

  • No share links. Dashboards live in your tenant, for Cockpit users.
  • No alerts or thresholds. Nothing watches a number and tells you when it moves. A workflow in Integration Studio is the place for that today.
  • No drill-down. Clicking a bar will not open the rows behind it. A table widget with the same filters is the substitute.

What to do now

The chart you will want first is almost always "revenue per account, 30 days against the 365-day average". You do not need the builder for it: the figures are on every organization's Orders tab today, and a segment on Revenue (30 d) and Revenue (365 d) gives you the list. Build the habit now; move it onto a board when the board exists.

What to check

Take one number from a new widget and reproduce it a second way: a CSV export, or the equivalent figure in the ERP. Do this once, when you build the chart. Nobody will do it later, and by then the chart will be in a meeting.

Next