Semaphor

Global Date Filter

Apply one date range across every eligible card on a dashboard.

Overview

A global date filter lets you set one date range at the dashboard level and have every eligible card pick it up automatically, with no need to configure the same date filter card by card.

Think of it as the dashboard's default time window. You set it once, and every eligible card with a clear date field respects it.

Plays nicely with your card-level dates

If a card already has its own date range on, say, order_date, the global range for that same field takes the lead while it applies, and the card's own range is kept safe and comes back when the global filter is cleared. Date filters on other fields keep working as usual. The two ranges are never merged, so a card never quietly shows a narrower window than you expect.


How it works

There are two ways to configure this:

  • On the dashboard, you add a global date filter. It automatically picks up each card's primary date field, so cards built on different datasets all filter correctly without any per-card setup.
  • On each semantic dataset, you mark one date field as the dataset's primary date field. This is the canonical date the global filter will target.

Which cards does this apply to?

The global date filter works with config-driven cards — the cards you build with the visual editor — whether or not they're on a semantic domain. If a card is on a semantic domain, you can set a primary date field on the dataset to tell the filter which field to use. SQL cards aren't touched by the global filter; they keep filtering exactly as their query defines.


Which date field each card uses (precedence)

When you add a global date filter, Semaphor picks which field to filter on for each card using a simple order of precedence. The goal is straightforward: cards that already have their own date behavior keep that behavior, and everything else picks up the dataset default.

  1. The card is already grouped by a date field. If the card breaks down its data over time (a trend over created_at, a monthly breakdown of order_date, etc.), the global filter targets that field.
  2. The card has a date field set for it. Single-value and aggregate cards can use a date field even when it isn't shown on the card.
  3. The dataset's primary date field. If the card is on a semantic domain and you've set a primary date field on the dataset, the filter uses that field.
  4. No date field to use. If none of these gives one clear field, the filter skips the card. On semantic-domain cards, that's usually a sign to set a primary date on the dataset.

When a card is skipped

A card with no clear date field simply keeps showing its own data. If a semantic-domain card you expected to follow the range doesn't, set a primary date on its dataset and it will pick the range up.


Set a primary date field on a dataset

Open a dataset with a date dimension in the semantic domain editor and toggle Set as primary date field on the column you want as its canonical date.

In YAML, it's a single key on the dataset:

datasets:
  - name: orders
    label: "Orders"
    primaryDateField: order_date
    fields:
      dimensions:
        - name: order_date
          label: "Order Date"
          dataType: date

The field you point to has to exist on the dataset and be a date or datetime type. If you rename the field later, the primaryDateField reference updates automatically.

For the full field authoring reference, see Datasets & Fields.


Add a global date filter to a dashboard

Open your dashboard in edit mode, open the filter side panel, and click Add global date filter at the top.

The filter shows up with a Global badge and a default title of Global Date. Click it to open the date picker and pick either a preset — Last 7 days, This month, Year to date, and so on — or a custom range with explicit start and end dates. The range applies to every eligible card immediately.

Default date ranges

You can save the dashboard with a sensible default range — for example, Last 30 days or This month — so it opens on the right window every time. Because the default is relative, it resolves freshly each time a viewer loads the dashboard.

Compare with another period

The Global Date control can also turn on comparisons across the whole dashboard. Pick a period to compare against once, and every eligible visual shows the change without you editing a single card.

  1. Choose a date range with a clear start and end.
  2. Under Compare, choose Previous period or Previous year.
  3. If you want, adjust how far back to look, turn To date on or off, or turn on Match weekdays.

The control tells you how many visuals will pick up your selection and how many already have their own comparison set by the author.

Your selection only reaches metrics the author left set to Inherit dashboard comparison. A metric with its own baseline, or one the author turned off, keeps that setting. Authors can also turn off inheritance for an entire visual.

Comparison waits for a real range

If the date range is All time, one-sided, an exact date, not between, or otherwise has no clear start and end, the comparison pauses and cards keep showing their current values. Pick a range with a start and end and the comparison comes right back.

Comparisons you start here use To date by default, which lines up the same elapsed stretch of each window. On July 11, for example, July 1 to July 11 compares with June 1 to June 11 rather than all of June.

Choose Reset to clear your comparison and return to the dashboard's saved default. It doesn't change the date range.

See Metric Comparisons for how baselines, visual support, and window behavior work in full.


Works alongside your other filters

The global date filter is independent of the other filtering mechanisms on a dashboard:

  • Card-subscribed filters ({{ filters | where }} in SQL queries) keep working exactly as before.
  • Dashboard controls ({{ param('id') }}) keep working exactly as before.
  • Date filters on other fields keep working as ordinary row constraints.

All of them can be active at the same time. For the same resolved date field, Global Date governs while applicable and the card-local range remains the fallback; the two ranges are not intersected.

On this page