Use cases
Dashboards enable you to:- Monitor key metrics – Display critical business indicators that refresh with live data
- Distribute analysis – Package your findings into reports for regular distribution
- Build data tools – Develop specialized applications powered by your semantic layer
- Present insights – Showcase important discoveries in a polished, accessible format
How it works
In the dashboard builder inside your workbook, select the reports you want to include and arrange them on the canvas alongside other widgets to tell your data story, then publish the dashboard. This gives stakeholders direct access to the insights that matter most, without the complexity of the underlying analysis. Prefer to manage dashboards from source control? You can also apply dashboards, workbooks, and reports to a deployment through the REST API and keep their definitions in Git — see Dashboards as code.Publishing and versions
A workbook holds a single dashboard, which stays a draft until you publish it. Click Publish in the dashboard builder to publish the current draft as a new version — viewers always see the latest published version, never your in-progress edits. Publishing is a workbook-level operation — the same one the as-code flow performs over the API. The button next to Publish reflects the dashboard’s state — click it to open the revision history:v{N}— the published version and your draft match.- Draft — you have unpublished changes.
Revision history
The revision history lists every published version alongside the current draft. Each row shows the version number, when it was published, and by whom. Select a version to preview it, then Restore to make it your current draft — publish again to make it the live version.What viewers see
When someone opens a published dashboard, a version chip in the header shows the live version (e.g.v3). Opening it reveals when that version was published and
a summary of what changed since the previous version — added, updated, or removed
widgets — so viewers can see which version they’re looking at and what changed in
it. (The chip is in-app only; it doesn’t appear on embedded
dashboards.)
Data freshness
Each widget shows a freshness leaf indicating how recently its data was refreshed. The dashboard’s own leaf reflects its least-recently-refreshed widget, so you can see at a glance whether everything on the dashboard is up to date.Linking between dashboards
Dashboards can link to one another. When a table widget shows a dimension that has links defined in the data model, left-clicking a cell opens a menu with those links: a drill-in link (dashboard:) navigates to
another dashboard in the same deployment, filtered by the values in the clicked
row, and an external link (url:) opens a URL. This is how you build
overview → detail flows — click a row in a summary dashboard to jump straight to
a focused dashboard scoped to that row.
Links are declared once on the dimension in the data model (not configured
per-dashboard), so every table that shows that dimension — in dashboards,
workbooks, embedded dashboards, and Explore — offers the same links. A drill-in
link targets a dashboard by its slug; see Dimensions →
Links to define them.
Dashboard slug
A dashboard can have a slug — a short, stable, human-readable identifier (e.g.orders-detail) used to link to it from the data model. Data-model
dimension links with a dashboard: value reference a
dashboard by its slug to drill into it.
To set it, open the dashboard in the builder, open the options sidebar, and
fill the Slug field. Slugs are unique per deployment and are resolved
within the current deployment, so the same model works across environments. The
dashboard’s own URL is unaffected (it stays publicId-based).
There is no required order between the model and the dashboard. You can
reference a slug from a
dashboard: link in the data model before any dashboard
uses it, or set a dashboard’s slug before any link references it — neither
breaks. A link whose slug doesn’t (yet) resolve is simply skipped in the cell
menu, and starts working as soon as a dashboard in the deployment claims that
slug. (If you later clear or change a slug that links still reference, the
options sidebar warns you to update those links.)Download as PNG, PDF, or CSV
Open a published dashboard, click the More actions (⋯) button in the
header, and choose Download as PNG, Download as PDF, or Print
version. The file is named after the dashboard’s title.
To export a single chart instead of the whole dashboard, hover the chart
widget, open its ⋮ menu, and choose Download as PNG or Download as
PDF — the same menu also offers Download as CSV for the chart’s
underlying data. The image captures just that chart, named after the chart’s
title.
PNG and PDF downloads are server-rendered snapshots — Cube re-opens the
dashboard (or, for a single chart, that chart on its own), waits for rendering
to finish, and captures the result. This can take up to a couple of minutes
for large dashboards. The control selections you currently have applied in your
browser are carried into a download you start yourself — filters, time
granularity switchers and field switchers alike. A scheduled
notification has no browser session, so its attachment renders the dashboard’s
own defaults, unless that notification carries selections of its own. (CSV is
generated from the data already loaded in the chart and downloads immediately.)
Downloading the whole dashboard requires Manage permission on the workbook
that owns it; exporting a single chart requires the Download data
permission. Both are hidden entirely when an admin turns off the account-wide
data download controls. The same screenshot
mechanism powers PNG/PDF attachments on notifications sent
after a scheduled refresh, and is also available
programmatically — see the Control Plane API.
Print version
Print version, directly under Download as PDF in the same menu, downloads the dashboard as a paper document rather than a picture of the screen. Where Download as PDF captures the dashboard’s grid as it is laid out, the print version rebuilds it for A4 pages:- Page 1 opens with the dashboard’s title and, under it, one read-only line
stating the control selections the file was made with, for example
Filters: Status is completed · Created at = Week. Every filter, time granularity switcher, field switcher and parent control that holds a value contributes to that line, hidden ones included. A dashboard with no controls, or none holding a value, prints no such line. - The controls themselves are left out: no dropdown, picker or clear button appears on the page.
- Every other widget — charts, tables, KPIs, text and AI summaries — prints full page width, one below another, in the order you read the dashboard: top to bottom, then left to right. Widgets inside a layout container print in the same flow, and a tabs container prints the widgets of every tab, in tab order, not only the tab on screen.
- A table prints every row its query returned, fitted to the page width, and continues onto the following pages with its column headers repeated at the top of each. A table row is never split between two pages.
- A chart, KPI, text or AI summary block that doesn’t fit in the space left on a page starts on the next page instead of being cut in two.
A pivoted table is the exception to the table rule above: it prints as a
fixed-height grid, the way it looks on the dashboard, so a long one shows only
its first rows.