What you will be able to do
- Explain why changing the underlying data does not refresh an AI/BI dashboard's cache
- Compare how scheduled refreshes help dashboards published with shared versus individual data permissions
- Choose a subscription preference for an existing schedule and identify the permission needed
- Distinguish dashboard UI schedules from Lakeflow Jobs dashboard tasks
1.Why fresh data alone doesn't mean a fresh dashboard
To load quickly, a dashboard checks two caches in order. It looks in the dashboard cache first, a 24-hour result cache that works on a best-effort basis. If there's no result there, it checks the generic query result cache. The two caches invalidate differently. The query result cache never returns stale data, because any change to the underlying data invalidates all of its entries. The dashboard cache is not invalidated or refreshed when the data changes, so it can serve results up to 24 hours old.
This is the main reason scheduling exists. A change to the underlying data does not refresh the dashboard cache, and refreshing the data as part of a pipeline step doesn't either. Apart from a scheduled refresh, the dashboard cache updates only when the dashboard runs a query the cache can't serve. Even current_timestamp() in your SQL won't help, because it invalidates the query result cache but not the dashboard-level cache.
The cache also has a cost benefit. Serving results from the dashboard cache doesn't start the SQL warehouse, because Databricks reads the cache without running a query. Multi-page dashboards add one more detail. When viewers open a published dashboard, only the datasets behind the active page run and get cached. When a schedule is set, every dataset refreshes on the schedule and its results are cached.
Checkpoint 1 of 6· Check yourself
Which action reliably refreshes an AI/BI dashboard's 24-hour dashboard cache?
Data changes, pipeline refreshes and current_timestamp() all leave the dashboard cache as it is. A dashboard schedule is the reliable way to refresh it.
“To reliably refresh the dashboard cache, configure a dashboard schedule.”Source: docs.databricks.com
Checkpoint 2 of 6· Exam question
A dashboard owner wants the regional-sales dashboard to refresh every Monday at 6 AM in the sales team's local time zone, without writing a raw cron expression. Which action configures this correctly?
Correct answer: A — Use the schedule dialog's frequency, start time, and time zone drop-down selectors without enabling cron syntax.
- A. This is correct because the schedule dialog's drop-down pickers can express a weekly cadence, a start time, and a time zone without ever touching cron syntax. That matches the requirement to avoid writing a raw cron expression.
- B. This is incorrect for the stated goal because it requires hand-writing a Quartz cron expression, which is exactly what the owner wants to avoid. Cron syntax is an optional path for patterns the drop-downs cannot express.
- C. This is incorrect because warehouse auto-start settings control when compute is available, not when a dashboard's queries actually rerun and refresh cached results. The dashboard itself would still show stale data until refreshed.
- D. This is incorrect because a Lakeflow Job reruns queries independently of the dashboard and does not populate the dashboard's own query result cache or refresh timestamp. The dashboard's built-in schedule dialog is the intended mechanism.
Sources1
2.Shared versus individual data permissions
How much a schedule helps depends on how the dashboard was published, because the publishing choice decides whose cache gets filled.
| Dashboard type | Caching type |
|---|---|
| Dashboard published with shared data permissions | Shared cache. All viewers see the same results. |
| Draft dashboard or dashboard published with individual data permissions | Per user cache. Viewers see results based on their data permissions. |
With shared data permissions, one scheduled run fills a cache that every viewer reads, which can significantly speed up the first load for all of them. Because results are cached and shared, the underlying SQL runs less often, which reduces compute costs and warehouse load.
With individual data permissions, each viewer has a per-user cache, so a single run can't warm everyone's view. A schedule is still useful here. Individual users can opt in to refresh-only schedules that trigger refreshes of their own cache, or subscribe and also receive notifications. Either way their personal cache stays current and the dashboard loads faster when they open it.
Checkpoint 3 of 6· Check yourself
A dashboard is published with individual data permissions. A viewer wants faster load times but doesn't want email. What fits?
Refresh-only participation keeps the viewer's per-user cache current without sending notifications. Pausing would stop the refreshes as well.
“users can opt for refresh-only schedules to trigger cache refreshes”Source: docs.databricks.com
3.Choosing how you take part in an existing schedule
You don't need to create your own schedule to benefit from one. Click Schedule to see the dashboard's existing schedules, then use the drop-down next to each one to set your preference.
| Preference | Effect for you |
|---|---|
| Inactive for me | Do not participate in this schedule |
| Refresh data for me | Trigger cache refreshes without receiving email notifications (refresh-only) |
| Refresh data for me & email | Trigger cache refreshes and receive email notifications |
Permissions decide whose participation you can change. With at least CAN VIEW on the dashboard, you can add or remove yourself as a subscriber to an existing schedule. To add or remove *other* subscribers, you need at least CAN EDIT. Subscribers can also be notification destinations rather than people, but a workspace admin has to define those destinations before anyone can select them.
Checkpoint 4 of 6· Check yourself
A user with CAN VIEW on a dashboard wants to add their whole team as subscribers to an existing schedule. What happens?
CAN VIEW is enough to manage your own subscription. Managing other people's requires CAN EDIT.
“add and remove yourself as a subscriber to an existing schedule if you have at least CAN VIEW permissions”Source: docs.databricks.com
Sources2
4.Dashboard schedules versus job-based refreshes
The dashboard's Schedule button isn't the only way to refresh a published dashboard on a recurring basis. Lakeflow Jobs can do it too: you configure a dashboard task that routinely updates an existing published dashboard, which is useful when the refresh needs to be part of a wider orchestrated workflow.
It doesn't. Schedule and subscriber lists that you create in the dashboard UI or API are distinct from the scheduling and automation that belong to a job. Each is managed in its own place, so adding someone to a dashboard schedule doesn't add them to a job's notifications, and pausing a dashboard schedule doesn't stop a job.
Schedules can also be created for you. If you publish a dashboard with dataset materialization enabled and it has no schedule yet, publishing adds a daily refresh schedule. Materialized data refreshes only on the dashboard's scheduled cadence.
Checkpoint 5 of 6· Check yourself
A team refreshes a dashboard with a Lakeflow Jobs dashboard task and also has a schedule in the dashboard UI. Which statement is correct?
The dashboard UI/API schedules and the job's schedules and triggers are separate mechanisms, and each is managed on its own.
“are distinct from scheduling and automation associated with a job”Source: docs.databricks.com
Checkpoint 6 of 6· Exam question
An analyst needs the operations dashboard to refresh every 15 minutes but only between 8 AM and 6 PM on weekdays, a pattern the frequency and period drop-downs cannot express directly. What should they do?
Correct answer: A — Select the Show cron syntax checkbox and write a Quartz cron expression that encodes the 15-minute weekday window.
- A. This is correct because Quartz cron syntax can encode narrow, recurring windows like a 15-minute cadence restricted to business hours on weekdays, which the simple drop-downs cannot represent. Enabling that checkbox switches the schedule editor into cron mode.
- B. This is incorrect because duplicating the dashboard multiplies maintenance and storage without producing the requested single, precise refresh pattern. The underlying scheduling limitation is not solved by adding more dashboards.
- C. This is incorrect because faster query execution does not create a recurring schedule; a dashboard without a configured schedule still only refreshes on manual triggers. Warehouse sizing affects query speed, not refresh cadence.
- D. This is incorrect because an hourly schedule does not run every 15 minutes, and the query result cache only reflects data from actual refresh events rather than inventing intermediate updates. The requested cadence would simply not be met.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Once the nightly pipeline reloads the source table, the dashboard automatically shows the new data.Why is that wrong?
Refreshing the data in a pipeline step does not refresh the dashboard cache, which can serve results up to 24 hours old. Configure a dashboard schedule.
Covered in Why fresh data alone doesn't mean a fresh dashboard
2.Scheduling is pointless for dashboards published with individual data permissions, because every viewer has their own cache.Why is that wrong?
Individual-permission viewers can opt in to refresh-only schedules, or subscribe, to keep their own per-user cache current.
Covered in Shared versus individual data permissions
3.A Lakeflow Jobs dashboard task and the dashboard's own schedule share one subscriber list.Why is that wrong?
Schedules and subscriber lists created in the dashboard UI or API are separate from a job's scheduling and automation.
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Dashboards maintain a 24-hour result cache to optimize initial loading times, operating on a best-effort basis.”
↩︎ Why fresh data alone doesn't mean a fresh dashboard“The query result cache never returns stale data, because a change to the underlying data invalidates all of its entries.”
↩︎ Why fresh data alone doesn't mean a fresh dashboard“Using current_timestamp() or similar functions in your SQL query does not invalidate the dashboard-level cache.”
↩︎ Why fresh data alone doesn't mean a fresh dashboard“Serving results from the dashboard cache does not start the SQL warehouse.”
↩︎ Why fresh data alone doesn't mean a fresh dashboard“If a schedule is set, all datasets refresh according to the schedule, and those results are cached.”
↩︎ Why fresh data alone doesn't mean a fresh dashboard“can significantly speed up the initial loading process for all dashboard viewers”
↩︎ Shared versus individual data permissions“refreshing the data as part of a pipeline step does not refresh the dashboard cache”
↩︎ Exam trap 1“The dashboard cache can return results that are up to 24 hours old even when the underlying data has changed”
↩︎ Prediction“To reliably refresh the dashboard cache, configure a dashboard schedule.”
↩︎ Checkpoint - 2.
“the underlying SQL queries run less frequently, reducing compute costs and warehouse load”
↩︎ Shared versus individual data permissions“Refresh data for me: Trigger cache refreshes without receiving email notifications (refresh-only).”
↩︎ Choosing how you take part in an existing schedule“if you have at least CAN EDIT permissions on the dashboard”
↩︎ Choosing how you take part in an existing schedule“Workspace admins must define notification destinations before they can be selected as subscribers.”
↩︎ Choosing how you take part in an existing schedule“users can opt for refresh-only schedules to trigger cache refreshes”
↩︎ Exam trap 2“users can opt for refresh-only schedules to trigger cache refreshes”
↩︎ Checkpoint“add and remove yourself as a subscriber to an existing schedule if you have at least CAN VIEW permissions”
↩︎ Checkpoint - 3.
“You can configure a task to routinely update an existing published dashboard.”
↩︎ Dashboard schedules versus job-based refreshes“are distinct from scheduling and automation associated with a job”
↩︎ Exam trap 3“are distinct from scheduling and automation associated with a job”
↩︎ Checkpoint - 4.
“If the dashboard has no schedule, publishing with materialization enabled adds a daily refresh schedule.”
↩︎ Dashboard schedules versus job-based refreshes