How to Send Power BI Reports After Data Refresh

Imagine your sales manager opening the daily PDF before the morning meeting. A large order came in late yesterday, and she is looking forward to seeing it in the total. It is missing. She asks you whether the report is wrong, and the meeting starts with a question about the numbers instead of a discussion about the business.

You check the email schedule: it ran exactly when it should. The trouble happened earlier. The overnight process that copies orders into the reporting database finished late, after Power BI had already refreshed. The PDF faithfully showed the data Power BI had at the time.

Moving the email back by fifteen minutes might help today. It does not tell you what will happen the next time the orders arrive late. What you need is for the work to happen in order: the orders finish loading, Power BI picks them up, and only then is the report prepared for your manager.

That is where PBRS helps. You can include the required Power BI refresh in the same job that prepares and emails the sales PDF, and configure how the job responds if refresh fails. The first decision is when to start that job, so it has the completed sales day to work with.

You may already have enough in Power BI for a simple daily email. Its After data refresh subscription runs after the first scheduled refresh of the UTC day. If that refresh reliably follows the completed overnight load, and the subscription meets your delivery needs, it may be a good fit.

For our sales manager, the difficulty is the late load. A second refresh later that day does not give you another native after-refresh email. If the report needs its own refresh, PDF delivery and response to a failure, those are good reasons to manage the routine together in PBRS.

Start by talking to whoever maintains the overnight order transfer. If it finishes reliably before a known time, you can plan the reporting job around that time. If its finish time varies, the application can request the prepared PBRS job once the orders are ready. PBRS also supports event-based schedules that check conditions such as a database record.

This conversation is worth having before you change another timer. It tells you what “ready” means for the figures your manager is waiting for.

Begin with the sales report and your own test mailbox. You want to see the same attachment your manager will receive before making it part of her morning routine.

Create the PBRS schedule, select the sales report, and choose PDF for the Email destination. Then open Refresh Datasets. Select the Power BI account, workspace and dataset used by that report, and add the dataset to the refresh queue. If the report depends on another model as well, include that dependency in your plan.

Next, decide what should happen on a morning when refresh fails. Enable the relevant notifications and review Raise an error if dataset refresh fails together with the job’s exception handling. The person responsible for the report should hear about the problem, and the delivery response should follow your team’s policy for incomplete figures.

The PBRS dataset refresh guide explains these settings and the post-refresh wait interval. Follow the guidance for your configuration; a chosen number of seconds, by itself, is not evidence that the required update has finished.

Try the morning your manager would actually experience

For the first test, let the order transfer finish and run the configured job. Open the attachment from the test email. Check the reporting date, the sales total and that late order from our example. You are checking the delivered document, because that is what your manager will use.

Then try a controlled failure of the required refresh. Confirm who receives the alert and what happens to the email step. Once both cases behave as intended, switch to the approved recipients and enable the planned schedule or trigger.

If your application already knows when the overnight order transfer finishes, it can ask PBRS to run the saved sales job at that point. Your reporting team keeps the report, refresh settings and email destination in PBRS; the application supplies the request to start.

First decide who handles the Power BI refresh. You can configure it as part of the PBRS job. Alternatively, your application may already perform and monitor it. In that case, wait for that specific refresh to complete before requesting the report, and confirm that it covers the intended sales day.

POST {pbrsBaseUrl}/api/Schedule/ExecuteScheduleAsync
Authorization: bearer {pbrsAccessToken}
Content-Type: application/json

{"ScheduleType":"report","uniqueid":101,"RunBy":"Sales data ready"}

GET {pbrsBaseUrl}/api/Schedule/GetExecutionStatus?ExecutionId={ExecutionId}
Authorization: bearer {pbrsAccessToken}

Return to that morning meeting. Your manager opens the PDF, finds the late order and gets on with discussing the sales results. You have a repeatable way to prepare the report, plus an agreed response for the mornings when the data is not ready.

Start with one report that someone currently checks or resends by hand. If a native daily subscription covers it, keep the routine simple. If you need to manage refresh, file preparation and delivery together, use that report to evaluate PBRS. The Power BI Report Automation page explains what else you can include as your reporting needs grow.

Download the PBRS Internal Evaluation Guide