Controls

Controls are widgets that let dashboard viewers change what’s shown without leaving the dashboard. The dashboard builder offers four control types:

• Filter — Narrow the data shown on the dashboard
• Time granularity switcher — Change the granularity of time-based dimensions
• Field switcher — Swap which dimension or measure the charts are built on
• Parent — Re-point several other controls at once from a single dropdown

The first three each target a member from your semantic model, and apply the viewer’s choice to every chart on the dashboard built on that member’s semantic view. Filters and time granularity switchers change how a member is queried — which rows come back, which buckets they fall into. A field switcher goes further and changes which member is queried at all. A parent control works one level up: it targets no member of its own and drives other controls instead.

​

Filter

Filter widgets let viewers narrow down the data shown on the dashboard. In the dashboard builder, open the Add Controls menu in the toolbar and choose Filter. The new filter is added in an unconfigured state — click Configure Filter (or open the widget’s settings menu) to pick a semantic view and a dimension.

​

Operators by dimension type

The available operators depend on the type of the underlying dimension: A time filter’s value is fixed or relative, picked on the value editor’s Fixed and Relative tabs: a calendar date, a whole-period preset — Today, Yesterday, This week, This month, This quarter, This year — or a single-moment relative value, offered as the 1 week ago, 1 month ago, 3 months ago and 1 year ago presets and typed with any other count in the custom N periods ago / from now editor. A between filter picks a calendar date for each bound on its Fixed tab, and one whole window — Past week to Past 2 years — on its Relative tab. Neither tab offers a list of values: each field takes one, and a between filter’s two fields fill its two-entry value array with one bound each rather than with alternatives. The Selection Mode switch is not offered for a time dimension either, so a time filter carries several values for one condition only when a hand-written URL parameter passes a list in its value — f_orders.created_at={"type":"equals","value":["2026-01-01","2026-02-01"]}.

​

Single vs. multiple selection

Filters can allow either a single value or multiple values. The filter’s edit sidebar sets this under Selection Mode, on a switch labelled Enable multiple values — offered on a string filter using is, and on no other combination. What each filter holds:

​

Default values

You can set a default value that’s applied when the dashboard loads. Defaults are useful for scoping the dashboard to “this quarter” or “the user’s region” without requiring viewers to interact with the filter first. Where the default comes from is set by the Default value dropdown in the filter’s edit sidebar, below Visibility. It offers one source at a time: Static defaults are configured by interacting with the filter in the dashboard builder — the value you select is saved on the widget and applied to every viewer when the dashboard loads.

​

User attribute default

Set Default value to From user attribute in the filter’s edit sidebar to pre-fill a filter from the viewer’s user attribute. When the dashboard loads, Cube looks up the attribute value for the current viewer and applies it as the filter’s default. This is useful for scoping a dashboard to the viewer’s own slice of the data — for example, defaulting a Region filter to the viewer’s region attribute, or a Sales rep filter to their email. To configure it: How the attribute value is matched to the filter: Empty, null, or unresolvable attribute values are skipped — the filter falls back to whatever static default it has, or no default if none is set. Saving the filter on From user attribute discards the value saved on the widget, as the warning above says, so a filter has this fallback only when you pick a value in it in the dashboard builder after that save. The user attribute default only seeds the filter’s initial value. Viewers can still change the filter unless its visibility is set to Disabled, in which case the resolved attribute value is locked against their own edits. Values passed via URL parameters also take precedence over user attribute defaults, so deep links continue to work. If a parent control drives this filter, the preset the viewer is on decides it — unless the link they opened carries a value for this filter, which wins at load. One that keeps the filter as-is lets the attribute seed it, and one set to Reset to default returns the filter to the value it opens on for that viewer — the attribute value when one resolves, otherwise its own static default; with neither, its default is no value, so the reset clears it. One set to Clear empties it and the attribute does not seed it back: the filter stays unfiltered until the viewer sets it or a value arrives in the URL.

​

Defaults resolved from the data

A saved value is fixed when you pick it, so it goes stale as the dimension’s values change: a filter defaulting to the newest release keeps opening on that release after the next one ships. The four remaining Default value options look the value up in the data instead, every time the dashboard opens: Rows where the dimension, or the measure you pick, is empty (null) are left out, so a default never resolves to an empty value while the dimension has others. When several values tie on the measure, Max value by measure and Min value by measure both take the one that comes first in the dimension’s own order: alphabetical for a string, lowest for a number, earliest for a time dimension. The filter then opens on the same value in the dashboard builder, on the published dashboard and on every load. The first and last value are offered on string, number and time dimensions. Picking either shows a sentence — The first value of Status, according to the selected sort order. — and a sort order dropdown beneath it:

• Natural, the default, is the dimension’s own order: alphabetical for a string, numeric for a number, chronological for a time dimension. The first value is the lowest, and the last value is the highest.
• Database is the order this filter’s own value list shows its values in, and is offered on a string dimension only. That list holds the first 100 values, so Last value of dimension under Database is the last of those 100 — not the last value the dimension holds.

The max and min options show a measure dropdown instead, grouped by semantic view, with nothing picked and the note Measures of views that share this dimension. under it. It lists the measures of the filter’s own view first, followed by those of every other view that includes the same dimension — one the data model declares as the same underlying cube member, the way a Customers view and an Orders view can both include the users cube’s city. For a measure of another view, the ranking query runs in that view, over its own copy of the dimension, and the value it returns is applied to this filter. A view is not matched by name: one holding a same-named dimension of a different cube offers no measures. Where no view has any measures to offer, neither option appears in the Default value dropdown. Until you pick a measure, the sidebar reads Pick a measure — otherwise the saved value is kept., and saving without one keeps the filter on Saved widget value. Choosing a different dimension for the filter also puts a data-resolved default back on Saved widget value, so pick the option again for the new dimension. A muted note right after the filter’s title, on the same line, names the source of its value, such as First value of Status or Max by Count. When the title leaves it too little room, the note is cut off with an ellipsis, and hovering it shows the whole note. On a published dashboard, the information icon at the end of the title line says the same: This filter’s value comes from First value of Status. Change it in the filter’s settings. The value is resolved for each viewer and never saved on the dashboard, so a published dashboard keeps following the data without being republished. A value set elsewhere still wins: a filter value passed in the URL replaces the resolved one, and so does a preset of a parent control that sets this filter to a value. The resolved value itself is never written into the URL. A parent control’s preset set to Reset to default returns the filter to the value the data resolves to, as if the dashboard had just opened. One set to Clear does not: A faceted filter resolves its default inside its facet scope, so the default is always a value its own value list offers, and it resolves again when a sibling filter changes. For a measure of another view, each sibling’s condition is carried over to that view’s matching dimension, and a condition with no match there leaves the filter with no value rather than resolving over rows its value list excludes. The warning icon described below names that case. When the data gives no value, the filter applies none: the note after its title reads No value applied, and a warning icon on the title line says why:

• The dimension returned no rows — for example, because the filter is faceted and a sibling narrows it to a period with none.
• The data could not be loaded — for example, because the query failed.
• The measure you picked has been removed from its view.
• The measure’s view no longer includes the filter’s dimension.
• A faceted filter’s sibling condition has no matching dimension in the view of the measure you picked, so it cannot be carried over. The measure itself is fine; the sibling filter’s dimension has no counterpart in that view.

In the dashboard builder, clicking the warning icon opens the filter’s settings, where you can pick another measure or option.

​

Faceted filters

When a dashboard carries more than one filter, you can mark one as faceted. A faceted filter scopes its value list to what its siblings are set to — selecting a value in one filter narrows the options shown in the faceted one, so viewers only see combinations that exist in the data. A sibling on the same semantic view narrows it directly; one on another semantic view narrows it once you match it to a dimension of this one. For example, on a sales dashboard with a Country filter and a City filter, marking the City filter as faceted means selecting United States in the Country filter limits the City filter to U.S. cities only. Mark both and each narrows the other. A faceted filter can take as a source any sibling, on its own semantic view or another, whatever condition that sibling is set to and whether or not it carries Facet itself — is and is not, the substring conditions, the comparisons on a Number dimension and every date condition are all read, and a Boolean dimension counts here too, its is true / is false setting is. That comes with qualifications:

• is null, is not null, is empty and is not empty carry no value and narrow as soon as they are set. Every other condition waits for a value, and until it has one it leaves the value list alone, just as it leaves the charts unfiltered.
• A condition and value that together leave nothing to scope by narrow nothing either, as the warning below sets out.

To pick which siblings a filter listens to, turn the Facet switch on in its edit sidebar: the source picker appears with it, reading All. The picker lists every other filter on the dashboard and greys out the ones it cannot use — a sibling whose condition cannot be used for faceting — with a tooltip saying so. A filter on another semantic view is selectable, and picking one adds a row under the picker for matching it to a dimension of this filter’s view. Left at All, the filter listens to every sibling on its own semantic view that the picker leaves selectable; picking entries narrows it to those. A filter you picked that later stops qualifying stays in the list with a warning icon rather than disappearing from it. Cancel leaves the filter on the sources it was last saved with — it discards every unsaved edit in the sidebar, not only the source list — while turning Facet back off clears the entries you picked, and the dimensions you matched them to, so switching it on again starts from All. A date source never scopes the value list to less than the window the charts are showing, so the list never drops a value the charts still have rows for. Which window it scopes to depends on the condition; is null and is not null name no window and scope by presence instead, to the rows with no date and to the rows with one: On after, after or on, before, before or on and between, the value editor picks a whole day for every bound, and on a whole day the scope takes the same bound the charts do — so a window they return no rows for leaves the value list empty too. A list that is being scoped does not necessarily look shorter — a long one fills the dropdown either way, and the values the window drops need not be the ones on screen. To check that a source is narrowing it, look for a value you know the window has no rows for and confirm it is gone from the list. Searching for that value is not a check: a filter’s value box takes values that are not in its list, so it offers back whatever you type. A faceted filter shows a facet icon on its title line, so you can tell which filters it is faceted by without opening its settings; a filter with Facet off shows none. Hovering the icon, or focusing it with the keyboard, lists the sources by title — Faceted by: Status and Created at. With the picker at All these are every sibling the filter follows, including filters placed in a stack, a grid or a tabs container; with entries picked, they are those entries and no other filter. A source the filter cannot use is left out: one on another semantic view you have not matched, and one whose condition cannot be used for faceting. A source is named by its condition, not its value, so it is listed while it waits for a value and in the cases the warning above lists, where its value leaves nothing to scope by. When no source is left — the filter is the only one on the dashboard, or every source you picked is one it cannot use — the icon stays and reads Faceted by: no other filter. In the dashboard builder, the tooltip adds Click to configure., and clicking the icon opens the filter’s edit sidebar, where the source picker is. The title line there ends with the widget’s settings menu, after the facet icon and any warning icon. On a published dashboard the icon appears only while the pointer is over the filter or keyboard focus is inside it, as a chart’s icons appear only while you hover the chart, and it only describes the filter and opens nothing. A source whose visibility is Hidden is counted there rather than named — Faceted by: Region and 1 hidden filter, or Faceted by: 1 hidden filter when every source is hidden — so the tooltip never names a control the viewer cannot see; a Disabled source is named. The dashboard builder names every source, hidden ones included. Deleting a filter takes it out of every source list it is picked in, together with the dimension it was matched to, and a filter left at All follows the siblings that remain.

​

Sources on another semantic view

A filter on one semantic view can narrow a faceted filter on another, once you say which dimension of the faceted filter’s own view the source stands for. Pick it in the source picker like any other sibling and a row appears under the picker: Based on names the source’s own view and dimension, and the picker beneath it — Matching dimension for “the source’s title” — takes a dimension of this filter’s view. The value list is scoped through that dimension, so the query behind it never names the source’s view. The match is part of the dashboard, so it applies on a published dashboard and in an embed too, including when the source’s value arrives in a URL parameter. The match is pre-selected for you when the answer is unambiguous: a dimension of this view the model declares as the same underlying column, then one the dashboard already maps that control to for a chart, then one matching by name and type. Several equally good candidates count as no answer, as does one of a different data type, and the row then opens unmatched. Only the dimensions the scope can use are selectable: one of the same data type as the source’s dimension, whose type can express the source’s condition. Nothing is stored until you Save, and clearing a match or unchecking the source drops it from the dashboard: picking that source again suggests a match afresh rather than restoring the one you cleared.

​

Time granularity switcher

Time granularity switchers let viewers change the granularity of time-based dimensions on the dashboard — for example, switching a revenue chart from daily to weekly or monthly. The widget targets a single time dimension and applies the chosen granularity to every chart that groups by that dimension. In the dashboard builder, open the Add Controls menu in the toolbar and choose Time Granularity. The new switcher is added in an unconfigured state — open its settings to pick a semantic view and a time dimension.

​

Allowed granularities

By default, viewers can choose between day, week, month, quarter, and year. You can narrow this list in the widget’s settings to only expose the granularities that make sense for the dashboard. For time dimensions backed by a TIMESTAMP or DATETIME column, sub-day granularities (second, minute, hour) are also available. DATE-typed columns don’t expose sub-day granularities, since they would bucket the entire day into a single point. Custom granularities defined in the data model aren’t offered in this list yet — the switcher exposes the built-in granularities only.

​

Default granularity

You can configure a default granularity that’s applied when the dashboard loads. If no default is set, charts use the granularity that was saved on the underlying report — viewers can still switch granularities, but the dashboard opens with each chart at its original granularity.

​

User attribute default

The default above is one granularity for everyone. To give each viewer their own, set Default value to From user attribute in the switcher’s settings and pick a user attribute. When the dashboard loads, Cube reads that attribute for the current viewer and opens the control on the granularity it names. This is how one dashboard opens at the interval each audience works in — daily for the operations team, monthly for the executives who read the same charts — from a single published dashboard. To configure it: The attribute value is matched against the granularity names the switcher allows — day, week, month, quarter, year, and second, minute, hour where the dimension exposes them — ignoring case and surrounding spaces, so an attribute reading Week resolves to week. The names are matched, not the labels the control displays, so one attribute works the same for viewers in every language. A value that isn’t one of the switcher’s allowed granularities — or is empty, null, or unresolvable — is ignored rather than forced, and the control falls back to the default granularity. Attributes are set per user and the allowed list per dashboard, so the two can drift apart without anyone editing either; the safe reading of an unusable value is “no opinion”. Viewers can still switch granularities unless the control’s visibility is set to Disabled, and their own pick outranks the attribute for the rest of the session. A granularity passed in the URL outranks both, so deep links continue to work. If a parent control drives this switcher and the preset the viewer is on maps a granularity to it, that mapping decides the granularity — a mapping the author made for that arrangement is more specific than a per-viewer starting point — unless a granularity for this switcher came in the link, which wins at load. A preset that keeps the switcher as-is has no opinion, so the attribute still seeds it. One set to Reset to default returns the switcher to the granularity it opens on for that viewer — the attribute granularity when one resolves, otherwise the saved default granularity — and clears it when neither resolves, a grain control’s default being no grain. A preset set to Clear empties the switcher and the attribute does not seed it back: it stays empty until the viewer picks a granularity or one arrives in the URL, so each chart falls to the granularity it was built with.

​

Field switcher

A field switcher lets viewers change which dimension or measure the charts are built on — swapping a revenue chart’s breakdown from Status to City, or its measure from Order count to Total revenue — without leaving the dashboard or opening the report. Where a filter narrows the rows and a time granularity switcher rebuckets them, a field switcher replaces the member itself in the chart’s query. One dashboard can then answer several questions that would otherwise need a chart each. In the dashboard builder, open the Add Controls menu in the toolbar and choose Field Switcher, then click Configure Field Switcher to set it up.

​

Choosing what it switches

A field switcher works on one member kind at a time — set Field Type to either Dimension or Measure. The rest of the settings follow from that choice: Alternatives come from the control’s own semantic view, and must be the same kind as the replaced member — a dimension switcher offers dimensions, a measure switcher offers measures.

​

Default option

The member a viewer starts on is set the same way a filter’s static default is: by picking it in the control while you’re in the dashboard builder. The selection is saved on the widget and applied to every viewer when the dashboard loads. If you never pick one, the dashboard opens on the replaced member. Removing a member from Alternatives after it was serving as the default clears the default, so viewers can’t start on a member the control no longer offers.

​

Default granularity per option

When a dimension switcher offers time dimensions, each of them can carry its own granularity, set under Default granularity per option. This exists because a swap otherwise inherits whatever granularity the chart already had. A viewer moving from Created at to a Completed at that only makes sense monthly would get the replaced dimension’s daily buckets, and the author would have no way to say otherwise. Each time option is either pinned to a granularity or left at Inherit from the chart, which is the default and the behavior of every control configured before this setting existed. Non-time options don’t have the setting, and a measure switcher has no granularities to speak of. If the dashboard also has a time granularity switcher pointed at the swapped-in dimension, the viewer’s own pick wins over the per-option granularity — a granularity a viewer actively chose outranks one the author set as a starting point. A granularity control nobody has touched does not.

​

User attribute default

Like filters, time granularity switchers and parent controls, a field switcher can start each viewer on their own member. Set Default value to From user attribute in the control’s settings and pick a user attribute; when the dashboard loads, Cube reads that attribute for the current viewer and opens the control on the member it names. This is how one dashboard opens on the breakdown each audience cares about — a Breakdown switcher opening on region for one team and channel for another, from a single published dashboard. The attribute seeds the selection, exactly as the default option does, and loses to a pick the viewer has already made. A member passed in the URL outranks both, so deep links keep working. If a parent control drives this switcher and the option the viewer is on maps a member to it, that mapping decides the member — unless a member for this switcher came in the link, which wins at load. An option that keeps the switcher as-is has no opinion, so the attribute still seeds it. One set to Reset to default returns the switcher to the member it opens on for that viewer — the attribute member when the switcher still offers it, otherwise its default option, and the member it replaces when no default option is set. A value that isn’t among the Alternatives is ignored rather than forced: the attribute is set per user and the options are set per dashboard, so the two can drift apart without anyone editing either, and the safe reading of an unusable value is “no opinion” — the control falls back to the default option.

​

What the swap preserves

The swapped-in member is queried under the replaced member’s output name, so everything the chart configured against that column keeps working across a switch — column formatting, sorting, pivots, and conditional formatting rules all survive, rather than resetting each time the viewer picks a different member.

​

When a chart can’t take the switch

Cube applies the switch in two places: to the SQL that runs, and to the query description the chart formats its results with. It applies the switch only if both take it — otherwise the chart would be labelled and formatted as one member while showing another’s numbers, which nothing on screen would reveal. When only one half can take it, the chart keeps rendering the member it was built on and shows a notice reading “The Field switcher could not be applied to this chart”. The usual reason is a query Cube can’t read back as semantic members — a hand-written one, or one built with a JOIN or UNION. The rest of the dashboard still switches. A chart whose query doesn’t use the replaced member at all is a different case: there is nothing in it to swap, so it renders unchanged and shows no notice. A chart with a period comparison is a narrower case: the comparison can’t follow a member switch, so the chart applies the switch and drops the comparison, saying so in its own notice rather than silently showing a comparison that no longer matches the data.

​

Parent

A parent control is a dropdown of presets you define. Picking one re-points a whole row of other controls at once — so a viewer makes a single choice instead of adjusting three or four filters by hand. Unlike the other control types, a parent control targets no member and never touches a chart query directly. It applies values to the controls it drives — its children — and those children then apply themselves to charts exactly as if the viewer had operated each one. Filters, time granularity switchers and field switchers can all be children; a parent control cannot be a child of another parent control. For example, an Analysis parent with the presets Retail, Wholesale and Promo can set a Channel filter, a Minimum order value filter, and a Date range filter to a different combination for each preset. Viewers see one dropdown; you can hide the children if the individual values aren’t worth showing. In the dashboard builder, open the Add Controls menu in the toolbar and choose Parent, then click Configure Parent to set it up — or let Add to Parent control create one from the values the controls hold. The editor gives each preset its own tab, and lists every filter, time granularity switcher and field switcher on the dashboard inside it — so one tab is one complete arrangement, and you can read off what a preset does to the whole row at a glance.

​

Presets

Each preset is a tab across the top of the editor. Add one with + at the end of the tab strip; it is named Preset, or Preset 2, Preset 3 and so on when that name is taken. Double-click a tab’s title to rename it — or press F2 with the tab focused — and delete one from the ⋮ menu that appears on the tab when you hover, which offers Rename and Delete preset. A parent control needs at least one preset, so Delete preset is greyed out while only one is left. A parent control can hold up to 50 presets. A parent control created without presets opens on a single tab named Default. That is a real preset — saved with the control and offered in the viewer’s dropdown like any other — so rename it if that label isn’t what viewers should see. Renaming a preset later doesn’t disturb the values you’ve mapped to it, so you can reword a label without redoing the mapping — but if the control has a user attribute default, that match is by label, so rename the attribute’s values with it.

​

Children

Each control on a preset’s tab carries a dropdown saying what that preset does to it. Every preset/child pair is in one of four states: A control you haven’t touched on a tab still reads as one of these: the first tab starts every control on Reset to default, and every later tab starts them on Keep as-is, so a new preset changes only what you actually set. The first tab’s displayed defaults become real mappings when you save — see what a save writes. While the parent’s settings are open, the controls it drives are outlined on the canvas, so you can see the scope of the mapping at a glance.

​

One parent per child

A control can be driven by only one parent control at a time. Saving a parent moves onto it every control it drives, rather than sharing them — and that includes rows you never touched on the first preset’s tab, since the save writes the Reset to default they display. The row names the parent that currently owns it, on any row this parent would drive. A row left Keep as-is is the exception: it’s the one state that doesn’t drive, so it moves nothing.

​

Mapping status on child controls

Once a dashboard has at least one parent control, every filter, time granularity switcher and field switcher on it shows a small indicator reporting how it’s driven: Set to, Clear and Reset to default all count as driving — each is something the preset does to the control; only Keep as-is doesn’t. Saving the parent’s settings fills in the first preset’s tab: every row there with no mapping yet is written as the Reset to default it displays, and no later tab is touched. So a parent that still has only its first preset drives every control on the dashboard the moment you save it, each reading Fully driven before you have mapped anything by hand. Add a second preset and saving moves them the other way: it leaves untouched controls as-is, so those same controls read Partly driven until that preset drives them too. This reaches controls another parent already drove. Only one parent drives a control, so saving a second parent takes them over. The Keep as-is exception is how you keep a control with its original parent: set it to Keep as-is on the second parent’s first preset, so its save writes nothing for that control — and leave the control alone on that parent’s other presets, since any one of them driving it claims the control anyway. So on a dashboard with more than one parent control, map the one you are editing deliberately rather than saving it to dismiss the dialog — the owner note tells you which controls a save would claim, but only if you read the rows. Click the indicator to open that control’s own settings, at its Driven by parent section.

​

Driven by parent

Once a dashboard has a parent control, every filter, time granularity switcher and field switcher carries a Driven by parent section in its own settings. It names the parent driving the control, or offers only None when nothing drives it yet, so you can see what drives a control without opening the parent. Picking None detaches a driven control: the parent’s mappings for it are dropped on every preset, so it stops driving, and the control keeps whatever value it is showing. That detachment is not durable on its own: it holds only until the parent’s settings are next saved, which drives the control again. To survive that parent’s own saves, set the control to Keep as-is on the parent’s first preset — that is a mapping of its own, and the save fills in only controls that have none. The later presets need nothing, since None has already cleared their mappings and untouched means Keep as-is there. That binds only the parent you set it in — a different parent claims the control on its own save unless you set it to Keep as-is on that parent’s first preset too. Mapping is the one thing you cannot do from here — the values belong to the parent’s presets. To map a control, or hand it to a different parent, open that parent’s settings and set the control’s row on each preset’s tab.

​

Default preset

A parent control’s default is set the same way a filter’s static default is — by interacting with the control in the dashboard builder. The preset you select is saved on the widget and applied to every viewer when the dashboard loads; there’s no static default field in the parent’s settings. Picking in the builder also applies that preset to the children and saves the result, so a published dashboard opens in a consistent state. What each state saves: A reset that resolved its value from your user attribute saves the child empty, so your own value is never pinned onto everyone and each viewer re-seeds from their own attribute. That clears the child’s saved default too: a viewer whose attribute doesn’t resolve then has nothing to fall back on, so re-set that default by hand if you want it kept. If you never pick a preset, the parent opens with nothing selected and the children use their own defaults. Clearing the parent later leaves the children where they are. So a parent that opens on nothing is not the same as children on their original defaults: pick a preset in the builder and then clear the parent, and the children keep the defaults that preset wrote. Set them by hand if that isn’t what you want to publish. Deleting the preset that was serving as the default clears it, and the parent goes back to opening on nothing.

​

User attribute default

The default above is one arrangement for everyone. To give each viewer their own, set Default value to From user attribute in the parent control’s settings and pick a user attribute. When the dashboard loads, Cube reads that attribute for the current viewer and opens the control on the preset it names — and drives the children with it, exactly as if the viewer had picked that preset themselves. This is how you ship one dashboard that opens differently per audience: a Reporting period parent whose presets are Month and Quarter, opening on whichever one the viewer’s reporting_period attribute says, with every control behind it already set to match. To configure it: The attribute value is matched against the preset labels, ignoring case and surrounding spaces — an attribute reading quarter selects the preset labelled Quarter. Give the presets the labels your attribute already uses, or adjust the attribute values to match. If the value matches no preset — or is empty, null, or unresolvable — the control falls back to the default preset you picked, and the children keep the arrangement that goes with it. Viewers can still switch to another preset unless the control’s visibility is set to Disabled, and their own pick outranks the attribute for the rest of the session. A shared link never changes which preset the recipient opens on: a parent control has no parameter of its own, so they resolve their own attribute, or the default preset, exactly as they would without a link. What a link does carry is the children of a preset the sharer picked by hand — the values of the ones it Set to — and those win at load over what the recipient’s own preset would have set. A preset that resolved from the sharer’s own attribute puts nothing in the link, children included, so the recipient’s own preset decides every child it drives. A control the sharer set by hand still travels by the ordinary rules.

​

Adding the controls’ values as a preset

Instead of mapping a preset row by row, you can set the controls on the dashboard itself and add what they hold to a parent control. In the dashboard builder of a published dashboard, pick values in its filters, time granularity switchers and field switchers. As soon as a control holds a value other than the one it was published with — a value you cleared, or one a parent control’s preset moved, counts too — a Control values changed button appears in the toolbar, after Add Other Widgets. It follows the control values only: adding, moving or editing a widget neither shows nor hides it, and a control added since the last publish has no published value to differ from. Before the dashboard’s first publish it never shows. Its menu offers two actions. Either one closes the menu and puts every control back on its published value, so the button goes away:

• Reset to published defaults does only that, and keeps every other change in the draft. When the values were the draft’s only change, the version button goes back to the published version.
• Add to Parent control first saves the values the controls hold as a new preset, described below.

Add to Parent control names the new preset Preset, or Preset 2 and so on when that name is taken, and adds it according to what drives the controls: On the new preset’s tab, each control whose value you changed is Set to the value it now holds (Clear, for a filter or time granularity switcher you cleared), and each control you left alone is Reset to default, so it still opens on its own default for each viewer, a user attribute value included. So the dashboard still opens on its published values, and the preset is one pick away: once you publish, viewers choose Preset in the parent control to switch to the values you saved. The parent’s settings open on the new preset’s tab, so you can rename it and check its rows. The preset is already part of the draft: Cancel closes the settings and keeps it. When Add to Parent control can’t add a preset, it stays in the menu, greyed out, and hovering it says why. Reset to published defaults still works:

​

Clearing and resetting

Every control offers at most one of two actions in the control itself, beside its dropdown arrow: Reset to default takes the one action slot in the control whenever it applies, so a control that has drifted from its published value offers the way back rather than the way to empty. The dropdown header is not limited that way — whichever of the two apply are there as text links, Reset to the left of Clear — and neither closes the dropdown. On a published dashboard, clearing or resetting changes only what that viewer sees, and writes nothing back to the dashboard. Neither action is recorded in the URL, so a reload reopens the control on whatever it opens on for that viewer. A control whose visibility is Disabled greys out whichever action it shows, so a viewer can see the state without changing it. In the dashboard builder both write the draft. Reset to default returns the control to the published value, so that control has no unsaved change left on it. Clear removes the control’s saved default, which viewers see once you publish; clearing a parent control removes the preset saved as its default and leaves the children’s saved defaults alone.

​

Sharing the current selection

On a published dashboard, the values a viewer picks in the controls are reflected in the URL, so the view they are looking at is bookmarkable and shareable. Copy the address bar, send it on, and the recipient opens the dashboard with the same filters, granularities and member choices applied. Each control type has its own parameter: The semantic view and member are the internal names configured on the control — not the display titles you see in the picker. A view shown as Orders is usually orders in the parameter. The same goes for the member on the right-hand side of ms_: it is the internal name of the member to switch to, and it is a measure rather than a dimension when the switcher’s Field Type is Measure. Granularities are lowercase and must be one of the switcher’s allowed granularities — day, week, month, quarter, year, plus second, minute, and hour for time dimensions that expose them. You can also write these parameters by hand to open a dashboard in a particular state — see Pre-set dashboard filters, granularities, and tabs via URL for the embedded case, which uses the same format. A filter’s JSON carries the condition in its type key, alongside the value. Omitted, it is equals, which is why the example above writes only a value. The strings for the conditions in Operators by dimension type: A Boolean dimension’s is true and is false sit on the is row: both are equals, with value set to the string "true" or "false" — f_orders.is_paid={"value":"true"}. A between filter’s value is a two-entry array, and both bounds are inclusive unless you set startInclusive or endInclusive to false. Each is a key of its own, beside type and value rather than inside them — f_orders.created_at={"type":"between","value":["2026-01-01","2026-02-01"],"endInclusive":false}. A substring condition takes caseSensitive the same way: with true the match is made with LIKE rather than ILIKE, so it respects case wherever the column’s collation is case-sensitive, and without the key case is ignored — f_orders.status={"type":"not_contains","value":"ship","caseSensitive":true}. The value editor has no switch for it, so a filter matches case only where a link sets the key. Outside between, a value may still be a list, and what a condition makes of one differs. is and is not read its entries as alternatives — f_orders.status={"value":["shipped","processing"]} — on a time dimension as much as a string or number one. A substring condition matches the entries joined with commas into one term, so {"type":"contains","value":["ship","proc"]} matches %ship,proc% and neither entry on its own. Every other condition reads exactly one value — the comparisons, and the in the … and not in the … family — and a list in their value leaves the widget unable to build its query at all. A parameter can also clear a control. A filter whose JSON has an empty value ([] or "") and no type, such as f_orders.status={"value":[]}, opens that filter cleared, and so does an empty granularity, tg_orders.created_at=. The control’s default does not fill it back in. Only a missing type clears. With any type written out, equals included, the filter opens on that condition: one that reads a value, such as {"type":"equals","value":[]} or {"type":"contains","value":""}, then has none, so it filters nothing and the default stays out as it does for a clear, with that condition picked; one that takes no value applies as usual, so {"type":"is_null","value":""} is is null. A viewer’s own clear still drops the parameter, as described below; this form comes from a hand-written link, or from the link a scheduled refresh sends for a control it clears. What travels in the link, and what wins when a link value arrives:

• Only what the viewer chose. Values that came from the control’s own configuration — a static default, a default granularity, a filter default resolved from the data — are not written into the URL. Every viewer already gets those from the dashboard itself, and leaving them out means a link stays correct after the dashboard’s defaults change.
• Never a personalized default. A value resolved from a user attribute stays out of the link — whether it seeded a filter, a time granularity switcher or a field switcher directly, or reached one through a parent control opening on the viewer’s own preset. Sharing a dashboard never pins your attribute value onto the recipient; they see it through their own attributes.
• Every control’s pick, together. Picking in several controls puts them all in the link, including when a parent control sets several children at once — filters, time granularity switchers and field switchers alike. A parent control isn’t serialized itself — the link carries the values the Set to children of a preset the sharer picked ended up with, while the parent dropdown opens on whatever default it resolves for the recipient, which may not be that preset. A preset the sharer never picked, resolved from the default or their own attribute, seeds its children as defaults and puts nothing in the link. What happens to children the preset cleared or reset is the bullet below.
• Neither a clear nor a reset. Clearing or resetting a control drops its parameter rather than recording the result, so the control is indistinguishable in the link from one nobody touched and the recipient opens it on whatever it opens on for them. The same holds for what a parent preset did to its children: of the four states, only Set to puts a value in the link by way of the preset. Clear leaves the child empty, and Reset to default lands it on a configuration or attribute value — or clears it where the child has no default — none of which go in the URL, by Only what the viewer chose and Never a personalized default above. So for either state the link carries nothing for that child. A child left Keep as-is is untouched by the preset, so it travels or not by the rules above: the viewer’s own earlier pick is in the link, a default is not.
• A link value wins at load. A parent opening on its own resolved preset leaves alone any control the link claimed, so the recipient sees the shared value rather than what that preset maps. For a child the link carries nothing for, their own preset decides: the same preset as the sharer’s re-applies that clear or reset, a different one does whatever it maps, and a parent resolving no preset leaves the control on its own default. Picking a preset by hand afterwards applies it, link or no link.
• Written out on published dashboards only. Reading these parameters works anywhere, including embedded dashboards; it’s the writing that is published-only. In the dashboard builder the URL is left to the editing session, so changing a control there doesn’t rewrite it.

When a dashboard opens with these parameters, they are applied on top of whatever defaults the controls carry. A parameter is ignored when nothing on the dashboard can honor it — there is no matching control for that member, the requested granularity isn’t in the switcher’s allowed granularities, or the selected member is one the field switcher doesn’t offer — its Alternatives, plus the replaced member. An f_ parameter is also ignored when its filter’s visibility is Disabled: the filter opens on the value it would have without the link. A time granularity switcher or field switcher set to Disabled still takes its tg_ or ms_ value.

​

Visibility

Each control has a Visibility setting that determines how it appears on the published dashboard. The setting applies to all four control types. Set the visibility from the Visibility dropdown when editing the control. Hidden controls remain visible in the dashboard builder so editors can reconfigure them, but disappear from the published view.

​

Interaction with charts

This section applies to filters, time granularity switchers and field switchers. A parent control has no member of its own and never applies to a chart itself, so it doesn’t appear in any chart’s Controls mapping — it acts only through the children it drives, and it’s those children that show up here. When a control is added to a dashboard, it’s automatically wired up to every chart built on the same semantic view as the control’s member. Charts built on other semantic views are left alone, so a dashboard can mix scoped and unscoped charts by default. Filters and time granularity switchers always target a dimension; a field switcher targets a dimension or a measure depending on its Field Type, and scopes on whichever it is set to. You can override this default per chart from its Controls mapping — disable the control for that chart, or remap it onto a different member. Adding a chart built on a different semantic view is the case where this needs attention. If at least one control has a mapping suggestion on the new chart’s view, a prompt appears with Review…, which opens the chart’s Controls mapping with the suggestions pre-selected, and Dismiss, which leaves the mappings as they are. If no control has a suggestion, no prompt appears, and you map controls to the chart by hand.

​

Incompatible controls

If controls of a certain type are incompatible with a particular chart’s query, the chart skips all controls of that type and renders the data without them. Each type is skipped independently — if filters fail but a time granularity switcher works, the chart shows the granularity-adjusted data without filtering, and vice versa. A field switcher that can’t be applied says so on the chart itself rather than through the icons below. The chart displays a warning icon to indicate the problem: Hover over the icon for details. Click it to open the chart’s Controls mapping and fix the issue — remap the control to a compatible dimension or disable it for this chart.

​

Controls mapping

Each chart decides which controls apply to it through its Controls mapping. The mapping is resolved automatically in most cases and only needs manual attention when a control targets a member that isn’t on the chart’s semantic view. Open Controls mapping from a chart’s settings menu to inspect or override the mapping for that chart. For each control on the dashboard you can:

• Toggle the control on or off for the chart, even when a mapping exists
• Pick a different member from the chart’s semantic view to remap the control to

Four states show up in the mapping sidebar: Two semantic views can share a member name and mean different things by it, so a suggestion reaches a chart only once the mapping is saved. Among members of the control’s type, an exact name match wins. Failing that, names are compared ignoring case, and a suggestion is made only when exactly one member matches. Controls you turned off for the chart are not suggested. Each control’s picker offers only the members it can actually be resolved against, so a mapping you can stage is a mapping that will work: For filter, time granularity, and field switcher controls — the three that map onto a member — the Workbook Agent can set the same per-chart overrides you would from Controls mapping: exclude a chart from a filter, or remap any of the three onto a different member for one chart. That lets it wire these controls across charts on different semantic views without you revisiting each chart manually.