> ## Documentation Index
> Fetch the complete documentation index at: https://cubed3-docs-cub-4941.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Dashboards

> Curate and share polished views of your workbook reports with stakeholders as interactive dashboards.

Dashboards let you select and organize reports from your workbooks into polished, shareable views for your team and stakeholders. Transform your exploratory analysis into production-ready deliverables by choosing which insights to highlight and present.

## 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][ref-workbooks], select the reports you want to include and arrange them on the canvas alongside other [widgets][ref-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](/docs/explore-analyze/dashboards/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](/docs/explore-analyze/dashboards/dashboards-as-code#4-publish)
performs over the API.

The button next to **Publish** reflects the dashboard's state — click it to open
the [revision history](#revision-history):

* **`v{N}`** — the published version and your draft match.
* **Draft** — you have unpublished changes.

Before the first publish, no button is shown.

While editing, **Undo** and **Redo** step through your draft changes, and
**Revert** discards all unpublished changes to restore the currently published
version.

### 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](/embedding/iframe/dashboards).)

## Data freshness

Each widget shows a [freshness](/docs/explore-analyze/workbooks/querying-data#result-freshness-and-provenance) 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][ref-dimension-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](#dashboard-slug); see [Dimensions →
Links][ref-dimension-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][ref-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).

<Note>
  **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.)
</Note>

<h2 id="download-as-png-or-pdf">
  Download as PNG, PDF, or CSV
</h2>

Open a published dashboard, click the **More actions** (`⋯`) button in the
header, and choose **Download as PNG**, **Download as PDF**, or [**Print
version**](#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][ref-controls] 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][ref-data-download-controls]. The same screenshot
mechanism powers PNG/PDF attachments on [notifications][ref-notifications] sent
after a [scheduled refresh][ref-scheduled-refreshes], and is also available
programmatically — see the [Control Plane API][ref-control-plane-api].

<h3 id="print-version">
  Print version
</h3>

**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][ref-control-visibility] 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][ref-layout] 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.

<Info>
  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.
</Info>

Your current control selections are carried into the print version exactly as
they are into **Download as PDF**, and it requires the same permission.
[Notification][ref-notifications] attachments and the Control Plane API don't
offer it: they always render the on-screen layout.

[ref-workbooks]: /docs/explore-analyze/workbooks

[ref-widgets]: /docs/explore-analyze/dashboards/widgets

[ref-controls]: /docs/explore-analyze/dashboards/widgets/controls

[ref-control-visibility]: /docs/explore-analyze/dashboards/widgets/controls#visibility

[ref-layout]: /docs/explore-analyze/dashboards/widgets/layout

[ref-dimension-links]: /docs/data-modeling/dimensions#links

[ref-notifications]: /docs/explore-analyze/notifications

[ref-scheduled-refreshes]: /docs/explore-analyze/scheduled-refreshes

[ref-data-download-controls]: /admin/users-and-permissions/roles-and-permissions#restricting-data-downloads

[ref-control-plane-api]: /reference/control-plane-api#apiv1deploymentsdeployment_iddashboard-exports