Dashboards

A chart is a saved SQL query plus a picture of its result: a bar, line, area, pie, scatter or funnel chart, a single number, or a table. A dashboard places charts side by side on a grid and puts filters above them, so one change — a date range, a region — reruns every chart it applies to.

A dashboard can also hold notes: Markdown text — a heading, an explanation, a link — placed on the grid like a chart, moved and resized the same way, and aligned left, center or right and top, middle or bottom within its space. A note sits on a card like a chart, or without one, straight on the page (a heading between rows of charts, for example). Notes belong to their dashboard.

Charts live in a library of their own (Dashboards › Charts) and are built once: the same chart can sit on any number of dashboards. Deleting a dashboard never deletes its charts, and a chart cannot be deleted while a dashboard still uses it.

Where charts read from

Source	What it reads
Honeybase	Your organization's own data — tasks, runs, processes, form responses — through read-only reporting views that only ever show your organization's rows.
Organization database	Your organization database, through its read-only user.
An SQL integration	A PostgreSQL, MySQL or Oracle database you connected, with the credentials you gave it.

Filters and parameters

A chart's SQL can declare parameters — {{period}}, or an optional clause such as [[AND created_at {{period}}]] that disappears when the parameter has no value. Each parameter has a type: text, number, date, date range or multi-select.

A dashboard's filters feed those parameters: on each chart you link a filter to one of its parameters of the same type. A filter can be typed freely, or offer a list of values — fixed, or the values of a column, which Honeybase keeps fresh in the background rather than reading the column each time someone opens the dashboard.

The values you apply go into the page's address, so a filtered dashboard is a link you can share: whoever opens it sees the same view. By default a filter applies as soon as you pick a value; a builder can turn that off so changes wait for Apply.

Colors

Charts use the theme's palette unless you pick colors in the chart editor's Colors section:

• Series and slices — a color for each line, bar, area or scatter series, each pie or funnel slice, or a number.
• Thresholds (number charts) — the number turns, say, red below 10 and green from 100, using the first threshold it matches.
• Rules (tables) — tint a whole row, or one column's cells, when a value is above, below, equal to, containing or empty; the first matching rule wins.

Each color is either a theme color — the palette's five, red, amber, green, blue or gray, which switch to their dark-mode shade with the rest of the screen — or a custom hex color.

Viewing

Full screen shows the dashboard alone on the screen, for a wall display or a meeting. Auto-refresh reruns every chart every 1, 5, 15, 30 or 60 minutes while the dashboard is visible; the choice is part of the page's address, so a wall display keeps it.

Who can do what

Every member can open dashboards, change their filters and export what they see (a chart as PNG, CSV or JSON; a whole dashboard as a PDF). Creating, editing and deleting dashboards and charts — and therefore writing SQL — needs the Manage dashboards permission, which the Owner, Admin and Builder roles have. Members who only view run the saved charts as they are: the values they pick are passed to the query as parameters, never pasted into its text.

Read-only queries

Dashboards only read. Two independent layers make sure of it, whatever credentials an integration uses:

1. Only a single SELECT runs. Before anything reaches your database, the query is parsed and refused unless it is exactly one SELECT. INSERT, UPDATE, DELETE, schema changes, settings changes, several statements in one text, SELECT … INTO, FOR UPDATE, and a WITH clause that changes data are all refused, and so are functions with side effects — on PostgreSQL for example set_config, nextval, dblink, pg_sleep, pg_terminate_backend and the advisory-lock functions; on MySQL sleep, get_lock and load_file; on Oracle anything in a DBMS_, UTL_ or OWA_ package.
2. Every query runs in a read-only transaction that is rolled back. On PostgreSQL and Oracle SET TRANSACTION READ ONLY, on MySQL START TRANSACTION READ ONLY; the transaction always ends with ROLLBACK, never a commit. A write that got past the first layer is rejected by the database itself.

Every query also runs under a time limit and a cap on the rows it returns.

Still connect with a read-only user

Those two layers cover what a query can say. They cannot see inside functions that already exist in your database: a function written to open its own connection (PostgreSQL's dblink or similar extensions, called from inside your function) or one declared PRAGMA AUTONOMOUS_TRANSACTION on Oracle runs its writes in a transaction of its own, outside the read-only one. Only people with the Manage dashboards permission write dashboard SQL, but the database user is the boundary that holds regardless.

So give the integration a dashboards uses a database user that can only read — on PostgreSQL, for example, a role granted CONNECT, USAGE on the schema and SELECT on the tables it should see, and nothing else. Each integration's page has the exact statements: PostgreSQL, MySQL, Oracle. If workflows also need to write to the same database, create a second integration with a separate, writing user for them.