Dashboard Variables — one control that filters every panel at once

A Variable is a value scoped to one dashboard, not one panel — set it once, and every panel on that dashboard can filter by it at the same time. No more editing five different panel queries every time a filter value needs to change, and no more copy-pasting the same WHERE condition into every new panel you add.

Variables bind into SQL exactly the way {from:String}/{to:String} already do — ClickHouse's own named query parameters, never string-interpolated into the query text. A variable named region is referenced in any panel's query as {region:String}.

Four ways to show a Variable

• Hidden — no control shown anywhere; just a fixed value only an Admin/Analyst can change. Useful for a constant several queries need to agree on.
• Checkbox — a toggle. Bound as a plain string: one value when checked, another (default empty) when unchecked — the query itself decides what each value means.
• Select — a single-choice dropdown.
• Multiselect — a checkbox-list dropdown that starts with every option selected. Uncheck the ones you don't want. Bound as a real ClickHouse array ({name:Array(String)}), so the query just uses IN.

Where the option list comes from

A Select or Multiselect needs a list of options from somewhere — two choices:

• Custom list — type the values in by hand, one at a time.
• SQL query — any query returning a value column (and optionally a label column, shown in the dropdown instead of the raw value). A common pattern adds a synthetic “All” option this way:

SELECT '' AS value, 'All' AS labelUNION ALLSELECT DISTINCT customer_type AS value, customer_type AS labelFROM chomper.eventsWHERE customer_type != ''

A Test query button runs it against your real data right there in the editor, before you save — the returned rows also become the default option for a Select.

Managing Variables

Open a dashboard, click Edit, then the gear icon next to the time range picker (Edit mode only — a Viewer never sees it) → Settings → Variables tab. The list stays collapsed to one line per variable so it's still readable with a dozen of them — click a variable's pencil icon to expand just that one for editing.

Removing a variable that's still referenced by a panel's query shows a warning naming which panel(s) would break first, instead of silently leaving them broken. Every change here — adding, editing, or removing a variable — goes through the same version history a panel/layout change does, so it's just as restorable.

Finding a Variable from inside a panel's query

Writing (or reading) a panel's SQL and need a reminder of what's available? Both the main query card and the drill-down query card in the panel editor have an “Available variables” link — opens every Variable this dashboard has, each with its exact {name:Type} binding one click away from being copied straight into the query.

Worked example

SELECT event_class AS name, count() AS valueFROM chomper.eventsWHERE region = {region:String}  AND ({vip_only:String} = '0' OR JSONExtractBool(metadata, 'is_vip') = 1)  AND source IN {sources:Array(String)}  AND timestamp >= parseDateTimeBestEffort({from:String}) AND timestamp <= parseDateTimeBestEffort({to:String})GROUP BY name ORDER BY value DESC

One thing to watch for: if two Variables narrow the same real column from different angles (say, a Select on event_class and a Multiselect on source, where each event class only ever comes from one particular source), their defaults can quietly contradict each other and return zero rows. Give the Select an explicit “all” option in its custom list (e.g. a value like (all)) and default to it, so the two controls don't fight by default — a deliberate, specific choice by whoever's using the dashboard should be what narrows things, not the starting state.