Global dashboard filters

what this feature is for previously, to filter dashboard data by «country», «dealer», «status», «owner», «team», etc , you had to open every widget and configure the filter individually on large dashboards this became tedious, and teams ended up duplicating dashboards just to serve different countries or departments dashboard global filters solve this filters are managed centrally from a dedicated filters panel they appear as dropdowns / date selectors at the top of the dashboard they apply automatically to every compatible widget when a new widget is added, the system tries to match a field to each filter by itself a single dashboard with global filters replaces dozens of «per country / per team» dashboard copies example instead of one dashboard per country, keep a single dashboard with a global «country» filter management picks a country — every widget refreshes where to find the feature global filters are available on every dashboard inside hyperbi in the dashboard header, next to the date range picker, there is a filters button with a slider icon once filters are created, they appear below the header as a row of «chips» that you use to apply values managing the list of filters clicking opens a right side panel with all filters for the current dashboard from this panel you can create a new filter (the button at the bottom) enable/disable a filter with the toggle (button) disabled filters don't appear on the dashboard edit a filter delete a filter x reorder filters by dragging — the row order in this panel defines the order of the chips on the dashboard creating / editing a filter clicking or the pencil icon opens a form (a separate panel) with the fields below title a multilingual name for the filter it's shown in the filter list (right side panel) as the chip label on the dashboard inside the filters dropdown on each widget select property the main section of the form — pick which field to filter by since a dashboard can include widgets built on different objects/flows, the filter has to be «wired» to each of them through its own field what's available search by property name property type filter (popover) — limit visible properties to one or several types supported text multitext date number entity checkbox below the search, selected types are shown as chips; remove a type with its cross icon below that — the list of target objects (definitionids)/flows each object expands into a list of its properties selection logic inside each block, properties are picked with a radio button — one filter = one field per object once you pick the first property, the filter's type is locked (for example, `date`), and the rest of the blocks filter themselves automatically to show only compatible properties for entity types, an extra rule only properties referencing the same object (definition) are shown e g , if you pick «owner → contact» in the first widget, the second widget will only offer entity fields referencing contact if the current user has lost access to the previously selected property (e g it was deleted), it's highlighted with a warning icon target widget the «target widget» collapse shows every widget on the dashboard and which field the filter will apply to in each of them \[ widget title ] → \[ property label ] \[ toggle on / off ] if the widget's object has a mapping — the toggle is active use it to disable the filter locally on this specific widget if the widget's object has no mapping — the toggle is disabled and the property slot is empty this block helps you see where the filter will actually work and lets you opt out specific widgets when needed custom dropdown (optional) by default the filter behaves like a widget «quick filter» the user picks an operator and a value but sometimes you want to restrict the choice to a predefined list — buttons like «last 7 days», «last 30 days», «this year», or «top tier dealers», «mid tier dealers» in custom dropdown you can add multiple options — each becomes a separate row in the dashboard dropdown set a multilingual label per option define the filter condition per option reorder options by dragging — the order defines the dropdown order if a filter has a custom dropdown, the dashboard renders it as a plain select with those options (instead of the popover editor) validation you can save a filter only if at least one title (title) is filled in at least one property is selected date filters for dates there are two range selection modes absolute (calendar) a regular calendar range start date and time — end date and time relative — presets a dropdown with predefined options \| preset | meaning | \| | | \| today | today | \| yesterday | yesterday | \| this week | the current week | \| last week | the previous week | \| this month | the current month | \| last month | the previous month | \| last quarter | the previous quarter | \| last year | the previous year | a relative preset is recalculated every time the dashboard is opened «last month» on may 1 and on may 30 will return different intervals 5 what is shown on the dashboard the chip label displays the preset name — if the current value matches one of them otherwise — `start end` as formatted dates what happens when a new widget is added when you add a new widget to the dashboard, the system tries to wire the existing global filters to it automatically — so you don't have to open every filter and add the field by hand how matching works for each enabled global filter if a mapping for the new widget already exists — skip it if the filter is of entity type — pick from the widget's properties if the filter already has mappings in other widgets referencing a specific object (e g contact), pick the first property that references the same object if the filter is any other type (date, text, number, checkbox, multitext) — pick the first property of the same type if nothing matches — no mapping is added; the filter won't apply to this widget manual override if auto matching picked the wrong field — just open the filter form and switch the mapping manually (section 4 2) any choice in the form takes precedence over auto matching cleanup when a widget is changed or removed if a widget's data source (object/flow) is changed and the old one is no longer used anywhere on the dashboard, it's automatically removed from all global filters if a widget is deleted, it's automatically removed from the «individually disabled» lists of every filter; and if no widget on the dashboard uses its data source anymore, that source is also removed from the mappings applying filters on the dashboard once filters are created and enabled, a row of chips appears below the dashboard header regular chip (no custom options) looks like \[ title │ value ▼ ] click opens a popover with the condition editor (the same one used in the table quick filter) — pick an operator and values there if multiple values are selected, the chip shows «value1 +2»; the full list appears in the tooltip on hover chip with custom options looks like \[ title │ select ▼ ] it's a plain select the user picks one of the predefined options the cross icon next to it clears the value where the values are stored the current filter values (what the user selected) live in the dashboard url — which means you can send the dashboard link to a colleague with the filter values already set reloading the page doesn't reset the values the filter configurations themselves (what the filter is, which mappings it has) are saved together with the dashboard behaviour at the widget level filter button on the widget if at least one global filter (with a non empty value) applies to a widget, its controls show a button with a number a filter icon plus the count of applied filters click opens a dropdown listing the applied filters each item has a cross icon — clicking it disables that global filter for this widget only ; other widgets on the dashboard keep using the filter as before this is handy when you need to «freeze» one widget in an unfiltered view while the rest of the dashboard keeps reacting to global filters how global filters combine with the widget's own filters if a widget has its own filter in its settings, global filters apply on top of it, joined with logical and in other words, a global filter always narrows the selection — it never expands it good to know read only users see every global filter and can change its values — those changes are applied locally, in their dashboard link they cannot edit the filter configuration (create, delete, change mappings) when editing a filter — if you change the property type, the mappings, or the custom options — the filter's currently applied values are reset, otherwise they would become invalid when editing a chip value, saving to the url happens with a small delay (about 500 ms), so the browser history isn't spammed and widgets don't recompute on every keystroke the special value «current user» (shown as «⚡️ me») is available in entity filters pointing to a user it automatically resolves to whoever is viewing the dashboard