How to Schedule Power BI Semantic Model Refresh

At 8:30, the operations team gathers to review orders and decide where to put people for the day. Their PDF is already in the inbox. But the last order shown is from yesterday afternoon, even though the overnight load finished an hour ago.

The report owner now has two jobs: find out which step ran too early, and send a replacement before the team makes its decisions. This is the gap PBRS helps close. It can include the required dataset refreshes in the report schedule, then prepare and deliver the output as part of that job.

What are you actually refreshing?

An Import semantic model holds a copy of data from your sources. Refresh brings that copy up to date. Microsoft now calls it a semantic model; you will still see dataset in PBRS settings and some API names.

To schedule the update natively, open the semantic model in Power BI Service and choose Refresh → Schedule refresh. Configure its connections, credentials, time zone and refresh times. The important decision comes before choosing a time: when will the source contain the information your team needs?

Suppose the overnight load normally finishes at 6:00. A refresh that begins at 5:45 can succeed perfectly and still miss those new orders. Scheduling the email for 8:15 will not repair that missing step.

DirectQuery and live connections work differently because most source data is not imported. Confirm the model’s connection mode before applying an Import refresh routine. This article concerns models published to Power BI Service; refreshing a file in Desktop or redrawing a visual is a different operation.

If your team only needs the online model updated at regular times, Power BI’s native schedule may be all you need. PBRS becomes useful when that update is one step in a larger promise: “Have the right report ready for the morning meeting.”

For our operations team, the second approach keeps the refresh, PDF and destination together. The report owner has one reporting job to maintain instead of separate clocks that happen to work on a quiet morning.

Leave room for the real working day

A scheduled refresh time is a planned start, not a delivery deadline. Microsoft targets starting within 15 minutes of the selected slot, but a start can be five minutes early or delayed by up to an hour when resources are unavailable. The refresh itself then needs time to finish.

Power BI Pro supports up to eight scheduled refreshes per day; PPU and Premium or Fabric capacity support up to 48. PBRS does not remove Power BI’s refresh limits or fix an unavailable source. Choose a cadence that fits both the business need and the model’s licensing and capacity.

See Microsoft’s scheduled refresh guidance for the current settings and allowances. If the source load varies substantially, improving the handoff from that load is more useful than repeatedly moving the refresh time later.

Begin with one report and one test recipient. The aim is to make the morning routine dependable before extending it to every department.

Make sure Power BI can reach the data

Work with the semantic model owner to review Gateway and cloud connections and Data source credentials. An on-premises source may need an online gateway with the right connection mapping. A directly reachable cloud source may not need one. Resolve those connections before diagnosing the schedule.

Run Refresh now, inspect Refresh history, and open the report to check a recent order. A successful test establishes that the service can retrieve the data; checking the order establishes that it retrieved the data you intended.

If you use the native schedule

In the model’s Refresh → Schedule refresh settings, enable the schedule, select the frequency, time zone and time slots, then apply the changes. Put those slots after the source is expected to be ready. Keep failure notifications directed to someone who can investigate.

If PBRS will refresh before the report

In the applicable PBRS report schedule, open Refresh Datasets. Select the Power BI account, workspace and dataset, then add it to the refresh list. Add any other required datasets deliberately; refreshing unrelated models adds work without improving this report.

Choose the completion or failure notification options and configure Raise an error if dataset refresh fails. Set the documented wait in seconds before report execution where needed. Review the schedule’s error handling so a refresh problem produces the response you want.

The PBRS refresh setup guide covers both report schedules and the independent Automation Schedule task. Avoid having an unrelated native schedule and PBRS repeatedly request the same refresh unless that overlap is intentional.

Finish the job your colleague will receive

Choose the report output and destination, then run the complete workflow. PBRS can carry the reporting process beyond refresh into export and distribution. For the operations team, that means the PDF is prepared and sent without someone opening the report and exporting it by hand.

Open the delivered attachment and check the new order or source-update time. Then test a failed refresh and a late source load. A fixed wait alone is not evidence of freshness: the finished file and the workflow’s failure behaviour are what matter to the reader.

Agree what happens when the 8:30 deadline cannot be met. A clear delay notice to the report owner is easier to manage than a replacement report arriving after the team has already acted on old figures.

Some mornings the load finishes at 6:00; at month-end it may finish much later. If your application knows when the data is ready, it can request the reporting job at that point instead of relying on another fixed time.

Configure and test the report schedule in PBRS first, including its refresh settings, output and destination. The application then asks PBRS to run that existing job. It does not need to rebuild the export and delivery routine each time the load completes.

POST /api/Schedule/ExecuteScheduleAsync
Authorization: bearer <access-token>
Content-Type: application/json

{
  "ScheduleType": "report",
  "uniqueid": 101,
  "RunBy": "Overnight load completed"
}

GET /api/Schedule/GetExecutionStatus?ExecutionId=<returned-execution-id>
Authorization: bearer <access-token>

Record the source-load identifier alongside the PBRS execution identifier in your application. That gives the report owner a practical answer when someone asks which overnight load produced the morning file. Still verify the output and destination; an accepted API request is only the beginning of the job.

The next morning, the team opens the PDF and sees the orders it expected. Nobody has to ask for a fresh export before the meeting can begin. That is the useful outcome of a refresh schedule: figures people can use when they need them.

Start with one recurring report, connect refresh to its preparation and delivery, and test both an ordinary day and a late load. PBRS gives the report owner a place to manage that routine as the audience and reporting requirements grow.

Explore PBRS reporting after dataset refresh and the wider Power BI Report Automation workflow. Use the evaluation guide below to try the complete process with your own morning report.

Download the PBRS Internal Evaluation Guide