5.2Scheduled refresh & gateway
The essentials in 30 seconds
- A published report shows the data from its last refresh; scheduled refresh replays the whole pipeline (Power Query included) at set times.
- Cloud sources (SharePoint/OneDrive): no gateway; local sources, yes — and then the standard enterprise gateway, never the personal one in production.
- The #1 cause of failures is credentials; you first look at the refresh history.
Running mini-case — Zineb automates the freshness of her report in Algiers
Zineb's sales report, a management controller in Algiers, shows yesterday's data: she wants it to refresh itself. She applies the cycle: she moves the source file to SharePoint (cloud source, no gateway), republishes, configures the semantic model's credentials, then enables scheduled refresh every day at 7 a.m. — before the viewers arrive. She modifies the source, runs "Refresh now" and checks the history. Her reflex: a failure? the history first, often an expired credential.
Standalone case for this section: it returns in the course, the diagram, the script and the 48h challenge of section 5.2.
1. Refresh replays the pipeline
A published report does not show live data: it shows the data from its last refresh. Scheduled refresh replays the whole pipeline — sources, Power Query, model — at set times. Hence the importance of clean queries: what breaks in Power Query breaks on every refresh. Zineb schedules her report every morning, without intervention.
2. Cloud or gateway
For cloud sources (SharePoint, OneDrive, cloud databases), the Service accesses them on its own: no gateway. This is the right reflex from the moment you choose the source location. For local sources (files on the network, internal SQL), you need a gateway: the bridge installed on the company side. And you choose the standard/enterprise one (on a server, supervised by IT), never the personal one for production — it depends on a PC being on. Zineb therefore switches to SharePoint.
3. Credentials, failures and history
The #1 cause of refresh failures is credentials: expired tokens, changed passwords. You configure them in the semantic model settings. In case of failure, the first reflex is to check the refresh history, which details the error. Zineb documents the accounts used to anticipate expirations.
🔎 Concrete example — 🔎 Concrete example — The freshness cycle
Zineb makes her report self-sufficient:
1. Source file on OneDrive/SharePoint → cloud source, no gateway
2. Service → Model settings → Credentials
3. Scheduled refresh: every day at 7 a.m.
4. Modify the source → "Refresh now" → check the historyReading: a published report is not live: it's the scheduling that brings freshness.
Lesson: cloud source = no gateway; a failure is diagnosed first in the history.
Section vocabulary
- Scheduled refresh
- Semantic model settings → Refresh: the times (up to 8/day in Pro, 48 in Premium) when the Service reloads the data.
Simple example: Zineb schedules her report every morning at 7 a.m.
What it is not: a forgotten manual refresh.
Reflex: fresh data → schedule.
- Gateway
- The bridge software installed on a company server: it lets the Service reach local sources securely.
Simple example: Zineb will need it for a file left on her network.
What it is not: a cloud source, reachable without a bridge.
Reflex: local source → gateway.
- Personal vs standard
- Personal: on your PC, for you (depends on your machine being on!); standard/enterprise: on a server, shared and supervised by IT.
Simple example: Zineb reserves the standard one for production.
What it is not: the personal one that stops if the PC is off.
Reflex: production → standard gateway.
- Credentials
- The access to the sources that the Service uses to refresh, to configure in the model settings.
Simple example: Zineb reconfigures access when a token expires.
What it is not: an access never entered, a source of failure.
Reflex: refresh failure → credentials first.
- Refresh history
- The log of attempts (successes/failures + detailed errors).
Simple example: Zineb reads the exact error there after a failure.
What it is not: a blind guess.
Reflex: "not up to date" → read the history.
In practice — In practice — Automating data freshness
- Move your source file to OneDrive/SharePoint and reconnect it from Desktop: cloud source = no gateway, like Zineb.
- Republish, then in the Service: Semantic model settings → Credentials → configure access.
- Enable scheduled refresh: every day at 7 a.m. — before the viewers arrive.
- Modify the source, run "Refresh now" and check the report AND the history.
Step-by-step script — making the report self-sufficient (5 min)
1) Store the source file on OneDrive/SharePoint and reconnect it in Desktop (cloud source, no gateway). 2) Republish the report to your workspace. 3) In the Service, open the semantic model settings and enter the credentials. 4) Enable scheduled refresh at 7 a.m., every day. 5) Modify the source, run Refresh now and check the history — like Zineb, the failure is read there first.
A refresh failure? The history gives the detailed error: most often an expired credential.
Copy-paste template — my refresh checklist
[ ] Source in the cloud (SharePoint/OneDrive) → no gateway
[ ] Local file? → STANDARD enterprise gateway (never the personal one)
[ ] Credentials configured (#1 cause of failures)
[ ] Scheduled refresh enabled (e.g. every day at 7 a.m.)
[ ] History checked after "Refresh now"Cloud source
Zineb moves her file to SharePoint: the Service reaches it on its own, without a gateway.
Local source
A file stays on the plant network: Zineb asks IT for the standard enterprise gateway.
Credentials
A token expires: Zineb reconfigures access in the model settings and restarts the refresh.
Every morning
Zineb schedules the refresh at 7 a.m.: when the viewers arrive, the data is already fresh.
✓ Best practices
- Choose cloud sources (SharePoint/OneDrive): no gateway needed.
- For local, the standard enterprise gateway — never the personal one.
- In case of failure, check the refresh history (often an expired credential).
✗ Common pitfalls
- Using the personal gateway in production (depends on a PC being on).
- Neglecting credentials (#1 cause of failures).
- Forgetting that refresh replays the whole pipeline (dirty queries = failures).
Key takeaways
- Refresh replays the whole pipeline: sources → Power Query → model.
- Cloud sources: no gateway; local sources: standard enterprise gateway.
- Credentials are the #1 cause of failures.
- Refresh failure: the history first.
48h challenge — apply it tomorrow
Make a report self-sufficient like Zineb: store the source in the cloud (no gateway), configure the credentials, enable scheduled refresh at 7 a.m., then modify the source and prove via the history that the refresh worked.
- I configure the scheduled refresh of a published semantic model.
- I know when a gateway is required and which one to choose.
- I favor cloud sources and I diagnose via the history.
Frequently asked questions
My refresh fails with a credentials error: what should I do?
It's the majority cause. Go to Semantic model settings → Credentials and sign in again: OAuth2 tokens expire and passwords change. Also check that the source path hasn't moved. Method: read the history (detailed error), reconnect the credentials, check the path — this trio solves the vast majority of cases.
Can I refresh more than 8 times a day?
In Pro: 8 times a day maximum; in Premium/Fabric: 48. Beyond that, you need to change paradigm (DirectQuery, streaming). But above all, ask yourself whether the business need justifies better than "every morning": in the vast majority of cases, a nightly refresh is enough.
When is a gateway necessary?