How to Configure the Calendar Visualization

The Calendar turns a report into a month-by-month grid where every dated row lands on its day — either colored by a value, so a wall of days reads like a heatmap, or labeled with a category, so each day shows a status, an owner, or an outcome.

Unlike a chart, the Calendar has one hard requirement: a date. Give it a date field and something to show on each day, and it renders. What your data decides is which of the two modes you use, and how much of the color legend, roll-ups, and click-through you get.

This guide walks the whole sidebar, in the order it appears, and explains why some options are missing until your data can support them. It finishes with the part most people skip until a dashboard drags: keeping the Calendar fast.

1. What your data lets the Calendar do

Two questions decide everything:

1. Does the report have a date column, and can Yurbi read it? Without one, there is no Calendar. This is the one non-negotiable.

2. What do you want on each day — a number or a label? That is the choice between the two Display Types.

The Calendar works best on detail rows — one row per dated thing (a ticket, an order, an event). It gathers all the rows that fall on a day and combines them for you.

The most important setup step: use a timezone-aware date field

Build your calendar's date field as DTZ or DOZ — not DAT or DPO. In the report builder, use Add Formula on your date field and change its type to DTZ or DOZ from the dropdown. Here's why it matters: a plain date type (DAT or DPO) is shifted by each viewer's browser time zone, which can push a day's rows onto the day before — an event on the 15th showing up on the 14th. The timezone-aware types (DTZ, DOZ) account for the offset and keep every row on its true day. Do this on the calendar's report and on any drill-down target report, so the days line up on both sides.

Date formats the Calendar understands

If your column holds real dates, skip this. It matters when dates arrive as text.

Use ISO (2026-03-15) whenever you can. It never gets read as the wrong day.

2. Display Type and Date Field

The top of the sidebar sets the two things the Calendar can't do without.

Display Type — Numeric (colored values) or Text (labels). Everything below changes to match: pick Numeric and you get value, formatting, and the color legend; pick Text and you get a label and how to resolve a busy day. Switching modes hides the options that don't apply — they aren't gone, they're just not relevant to the mode you're in.

Date Field — the column that places each row on a day. Only columns Yurbi can read as dates appear here. If yours isn't listed, its values aren't consistently readable — see the pitfalls in section 11.

3. Numeric mode — Value, busy days, and comparison

Current Value Field

The number the day is colored by. It should be a numeric column. If it isn't, the Calendar still works, but it can only count rows (see below) — it can't sum or average text.

When a day has several rows

Detail data usually has more than one row on a day. This is how those rows become the single number the day shows.

Options: Sum, Average, Minimum, Maximum, Count of records.

If the value field isn't numeric, this locks to Count of records automatically — counting rows is the only thing that makes sense for text, and it's often exactly what you want ("how many tickets opened that day").

Comparison Value Field (optional)

An optional second number to measure the day's value against — useful with the gradient legend, or to show movement rather than a raw level. Comparison to Zero decides what to show when that second number is zero: Infinite, Absolute, NoData, or Current. Leave the comparison field empty and none of this applies.

4. Text mode — Label and how to pick one

Text mode writes a word on each day instead of coloring it. It's how you build an at-a-glance status calendar — the day's dominant outcome, the on-call owner, the busiest category.

Label Field

The column whose value is written on the day — a status, a name, a category.

When a day has several rows, show

A day usually has several rows, so which label wins?

Ties break alphabetically, so the same day always resolves the same way.

Rank By (measure)

Appears only for Top label by a measure. The measure totaled per label to decide the winner — e.g. label each day with the product line that booked the most revenue: Label Field = product line, Rank By = revenue.

5. Number Format (Numeric mode)

How the value is written on each day — it never changes the underlying number.

Format Type: None, Fixed Point, Percent, Large Number (1.2M), or Currency. Decimal Places and Currency Code sit here when they apply.

6. Color Legend (Numeric mode)

This is where the Calendar earns its place on a wall: the rule that turns each day's number into a color.

Show Legend turns the whole thing on. Legend Position places the legend — Top or Bottom, Left / Center / Right. No Data Color / Text is the color for days with no rows.

Legend Mode

• Static — discrete color bands you define. Each band is a rule: a Threshold Type (Greater Than, Less Than, Between, Equal To, No Data), its value(s), a Label, and a Color / Text Color. A day takes the color of the first band it matches.

• Gradient — a continuous color scale across a range rather than discrete steps.

Bands, priority, and the coverage strip

Add bands with Add New, or edit them all at once as Bands (JSON). Two things make bands easy to get right:

• Order is priority. Bands are checked from the top down, and a day takes the first band it matches — so put your most important band on top. Use the row arrows to reorder.

• The coverage strip. Beneath the bands, a read-only bar lays your bands out across the range of values and points out gaps (values no band covers) and overlaps (values two bands claim, where the top one wins). It catches the classic mistakes — 1–10 then 11–20 leaves 10–11 uncovered; 1–10 then 10–20 overlap at 10.

A day whose value matches no band takes the No Data color, so a final band that covers everything else is a good habit.

7. Display Options and roll-ups

Layout and the running totals down the side.

• Column Layout — 1 Column or 2 Columns of months.

• Week Start Day — Monday or Sunday. Match what your business uses; it moves every week boundary.

• Show Week Totals / Show Week Average — a figure at the end of each week row.

• Show Monthly Average — a figure for the month.

• Show Today Highlight — marks the current day.

Totals and averages are calculated from your underlying data, not from the rounded numbers shown on each day. A weekly total adds up that week's data; a weekly average averages it. So you can show a daily average in each day and a weekly total down the side, and both are correct. In Text mode, the roll-up reports the period's most common label.

8. Interactivity

Drill-down

Set a Target Report and each day becomes clickable: clicking a day opens that report filtered to that day — the whole day, timestamps and all.

• Select Date Field tells the Calendar which field in the target report to filter. The target must contain that same underlying date field for the filter to carry across; if it doesn't, the field is simply ignored.

• Use Criterias passes the source report's own filters through to the target as well, so the drilled report stays scoped the way the Calendar is.

For the day to line up correctly, the target report's date field should also be a timezone-aware type (DTZ or DOZ) — see the tip in section 1.

Filters and prompts

You don't have to bake every filter into the report. Include a field but set it non-visible, and it can still power a dashboard filter or a report prompt — so a viewer can segment the calendar on the fly by a product line, a state, a customer, whatever matters, without that column crowding the days.

When Use Criterias is ticked, that live selection travels with the click: drill into a day and the target opens filtered both to that day and to whatever the viewer had chosen — as long as the target report contains the same field. (Those non-visible filter fields are also the performance tip in section 9 — they keep your rows collapsed.)

9. Performance — keeping the Calendar fast

The Calendar runs its report like any tile, and its cost is the cost of that query and the number of rows it hands back. A Calendar reads detail rows — so it is exactly the kind of tile that pulls a lot of data if you let it. Three levers, cheapest first.

9.1 Constrain the date range

A Calendar shows a window of time — rarely every row ever recorded. Constrain the report to the window you actually want on screen.

How to do it

1. In the report builder, open the action menu on your date column and choose Add Criteria.

2. Set the Conditional to Is.

3. Instead of typing a date, pick a predetermined range — Year to Date, Last Year, Last 3 Months, Month to Date.

4. Save the report.

Your data keeps growing; your Calendar's query doesn't. Year to Date or Last Year is usually the right bound for a Calendar tile.

9.2 Filter to the subset that matters

If the Calendar is about open tickets, filter to open tickets:

status   Is   Open

Every row nobody is looking at is a row the database read and sent for nothing. Narrow to what the Calendar is actually about — a region, a product line, a status, an active flag. Keep filter-only columns non-visible (9.4).

9.3 Pre-aggregate when there's a lot per day

The biggest win for a busy Calendar. If your source has many rows per day — hundreds of transactions a day — the Calendar reads them all and combines them on every load. Do that reduction once, in the report instead:

How to do it

1. In the report builder, choose Add Formula to create a date column reduced to the day, and set its type to DTZ or DOZ (section 1).

2. Add a second Add Formula for the value, choose Aggregate, and wrap your value column in Sum (or the aggregate you want each day to show).

3. Remove — or set non-visible — every other column so nothing else splits the rows apart.

4. Save and run. The report should now return roughly one row per day.

The Calendar behaves identically and loads in a fraction of the time.

9.4 Don't let filter columns fragment your rows

The most common reason an aggregated report still comes back huge. You reduce to one row per day, then leave customer_name in the report to filter on it — and now you have one row per day per customer, back to thousands of rows.

A field can be used in criteria while non-visible. In the field's action menu, turn Visible off. The filter still works; the rows stay collapsed. Every column you leave visible is a column the database has to group by — if the Calendar doesn't show it and nothing filters on it, remove it.

9.5 When to stop fighting the report

If the shaping you need can't be expressed with criteria, formulas, and non-visible columns, move it into the data: a database view, a Direct SQL query, or a stored procedure surfaced through your app. Aggregating millions of rows to a day belongs in the database, not in a report that redoes it on every dashboard load.

10. Two worked examples

A colored heatmap of daily volume

Display Type: Numeric · Date Field: opened_date (DTZ) · Current Value Field: ticket_id · When a day has several rows: Count of records · Color Legend: Static bands — Between 0–5 green, Between 6–15 amber, Greater Than 15 red. Each day is colored by how many tickets opened, and the coverage strip confirms there's no gap between the bands.

A status-per-day calendar

Display Type: Text · Date Field: order_date (DTZ) · Label Field: status · When a day has several rows, show: Top label by a measure · Rank By: revenue. Each day shows the status carrying the most revenue that day — so March 2 reads Delayed even though only one of its two orders was.

11. Common pitfalls

12. Checklist

Before you build a Calendar

• [ ] Is the date field a timezone-aware type (DTZ or DOZ)?

• [ ] Does the report have that date field in one consistent format?

• [ ] For Numeric mode, is the value column typed as a number?

Before you configure it

• [ ] Right Display Type — Numeric to color, Text to label?

• [ ] Right When a day has several rows rule for how busy days resolve?

• [ ] For Numeric, do your bands cover the range with no gaps (check the coverage strip)?

Before you put it on a dashboard

• [ ] Is the report constrained by date (Year to Date, or Last Year)?

• [ ] Is it filtered to the subset the Calendar is about?

• [ ] If a lot happens per day, is the report pre-aggregated?

• [ ] Are filter-only columns set non-visible?

• [ ] For drill-down, is the target report's date field also DTZ / DOZ?

The Calendar will work without all of this. Your dashboard will be quicker, and your days and click-throughs will land correctly, with it.

Related

• How to Configure the KPI Card Visualization — a single number, when a whole grid of days is more than you need