Power BI / Intermediate: context, quality and access / Lesson 12

Refresh, gateways and freshness evidence

Trace source availability, preparation, model refresh and report observations without equating a published file or successful schedule with current data.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Separate import refresh from visual query and source freshness.
Explain a gateway’s connectivity and ownership role.
Define freshness using data timestamps and quality checks.

Draw the refresh chain

An import model contains a loaded copy whose freshness depends on successful source extraction and processing. Refreshing a visual can query that existing model without importing new source rows. Publishing a file is another separate event. The first diagram separates source data time, extraction, Power Query evaluation, model processing and report query. A green task status cannot prove that the upstream source had already received the latest business events. Define a freshness claim in terms of usable data and a known cutoff, not only the time a browser page was opened or a task finished.

text Freshness has several timestamps

business event time -> source availability
  -> extraction/Power Query -> semantic-model processing
  -> report query -> displayed result
record separately: last task completion and latest usable data cutoff

The diagram is a synthetic evidence chain, not a service refresh log or an executable workflow.

Understand gateway responsibility

A gateway can provide the service an approved path to sources it cannot reach directly. It does not cleanse data, grant every user source access or make a powered-off machine available. Standard, personal and virtual-network gateway scenarios have different ownership and capability boundaries, so consult the actual documented deployment choice. Source mapping, credentials, availability and permissions all matter. This lesson installs no gateway, opens no network path and reads no credentials. A Desktop refresh succeeding on an author’s machine does not establish that the service has an equivalent source path or identity.

Classify refresh failures

A failure can occur before connection, during authentication, source query, transformation, schema handling or model processing. Preserve the exact stage and a safe synthetic reproduction rather than changing credentials for every error. A renamed column can break a later transformation even when the source is reachable. An expired credential differs from a privacy combination error, and a timeout differs from missing rows. Use approved evidence from the responsible owner. Avoid putting connection strings, private values or tokens into an editorial incident record, and do not disable privacy or widen permissions merely to make a task turn green.

Calculate a data-age oracle

The second example compares a synthetic observation time with the latest usable data timestamp. A model can finish refresh at10:00 while its newest usable data is from09:30; observed at10:15, the data age is45minutes. The program omits ingestion delay details and time-zone conversion, using explicit UTC values. It is not a service health check. A useful report can expose a clearly defined data cutoff and distinguish it from last processing completion. Also retain row-count or amount reconciliation so a recent timestamp cannot conceal an incomplete extraction.

python Synthetic usable-data age

from datetime import datetime, timezone
observed = datetime(2026, 1, 2, 10, 15, tzinfo=timezone.utc)
data_cutoff = datetime(2026, 1, 2, 9, 30, tzinfo=timezone.utc)
print(int((observed - data_cutoff).total_seconds() // 60))

Expected output

45minutes is an exact difference between these UTC timestamps. No gateway, source or Power BI service is queried.

Define handoff evidence

A refresh handoff records model identity, storage mode, source owner, intended schedule, last completed task, latest usable data cutoff, reconciliation and unresolved errors. Refresh limits and available scheduling features depend on license/capacity and current service rules; do not copy an old universal frequency claim. This course executes no refresh, sign-in or gateway request. Its timestamp subtraction supports one expected result only. A separately authorized review must validate actual mapping, credentials, source accessibility, processing and report behavior, keeping those claims distinct instead of describing a saved schedule as a tested freshness guarantee.

Common errors and fixes

Refreshing a visual is assumed to reload import data

Why it happens: Report query and semantic-model refresh were conflated.
How to fix it: Identify the model’s storage mode and the actual completed operation.
Prevent it next time: Name each freshness timestamp and event explicitly.

Desktop success is treated as service-source connectivity proof

Why it happens: Different machine paths and identities were ignored.
How to fix it: Review the approved service connection/gateway mapping and owner evidence.
Prevent it next time: Keep Desktop and service validation records separate.

A recent completion time hides stale or incomplete source rows

Why it happens: Task timing replaced data-cutoff and reconciliation evidence.
How to fix it: Compare latest usable data and expected row/amount coverage.
Prevent it next time: Expose a defined cutoff and quality status with refresh monitoring.

Check your understanding

1. Why can a10:00 successful refresh still show09:30 data at10:15?

Show worked solution

The source or extraction may only have supplied data through09:30. Completion time describes processing, not event freshness. The synthetic age is45minutes. Review upstream availability and data completeness before blaming the visual, and document which timestamp the report calls last refreshed.

2. A service refresh fails after a source column is renamed. Should permissions be widened first?