Warn users in time by putting the warning where they read the figures, rather than sending it only to the data team. First, gather all known quality issues in one place and link them to the reports that depend on the affected data. Then show the reader a simple warning: a status line in the report, an alert or a message in the channel they use. Explain what is wrong, how long it has been happening and who is fixing it.
Why the reader usually spots the problem first
The conventional view is that data quality is the data team's responsibility. The team monitors it, receives alerts and fixes issues. The reader should not have to notice anything.
But the reader does notice, just too late. For example, the sales report is on the agenda at Monday morning's weekly meeting. Saturday's data load partially failed, so one region is missing. The data team has seen the alert and is working on it. The sales director does not know this and asks why revenue in the north has collapsed.
In practice, that is when trust disappears. Not because the data was wrong once, but because the reader had to discover it themselves.
Where should the warning appear?
There are several ways to communicate data quality issues. The main differences are who sees the warning and when.
| Approach | Who sees it | When | Reaches the reader |
|---|---|---|---|
| Alert in a monitoring tool | The data team | Immediately | No |
| Email when a Power BI refresh fails | The semantic model owner | Immediately | No |
| Teams message or email to users | Whoever reads it | When someone remembers | Sometimes |
| Manually added text in the report | Everyone who opens the report | When someone updates it | Yes, if someone remembers |
| Status line in the report, driven by your own checks | Everyone who opens the report | With every check | Yes |
Only the last two reach the reader when it matters. And only the last one does not depend on someone remembering.
What a good warning says
A red dot alone does not help. It worries the reader without telling them what to do. A useful warning answers four questions.
- How serious is it? Use three statuses: OK, caution, do not use.
- What is wrong? Use plain language, for example "figures for the North region have been missing since Saturday".
- Who is fixing it? A name, not a team.
- What should you do now? For example "use last week's report" or "wait until Tuesday".
How do you set this up for Power BI reports?
Start small, with the reports used in management meetings.
- Choose a few checks for each dataset that the reader understands: is the data up to date, is it complete, are the values within a reasonable range.
- Gather the results in one place and link each check to the datasets and reports that depend on it. Without that link, you do not know which readers to warn.
- Agree with the owner of the figure on when the status should be "caution" and when it should be "do not use".
- Show the result where the reader is looking. In Power BI, you can do this with a status table in your semantic model and a line of text at the top of the report. Reach anyone who does not open the report with an alert or a Teams message.
- Close the loop: once the issue is resolved, the warning disappears automatically.
A practical framework: Measure, Link, Translate, Show, Close
- Measure: a handful of understandable checks per dataset, such as freshness and completeness.
- Link: gather the results in one place and link each check to the reports that depend on that dataset.
- Translate: turn the result into one of three statuses, with a one-sentence explanation and an owner.
- Show: put the warning where the reader already looks, in the report or their usual channel.
- Close: the warning disappears as soon as the issue is resolved.
Where dScribe fits
You build the warning that readers see in the report into your own report or alerting setup. dScribe helps you know what to communicate and delivers some of those warnings directly to the reader. In the dScribe app, you can see all data quality issues in one place, in a marketplace. dScribe makes the same information available through an MCP server. This lets you use it in your existing AI workflows, so a chatbot or agent answering a question about a report also knows about any known issues.
In Power BI, the dScribe browser plugin shows the definition and owner alongside the figure, and failed runs as alerts. This lets readers see that a data load failed before they discover the problem themselves.
Final thoughts
Poor data quality is inevitable. Making readers discover it themselves is not. As long as warnings only reach the data team, the business will keep making decisions based on figures that someone already knows are wrong. Get the warning to the reader, keep it simple and put a name to it.
Frequently asked questions
How do you show data quality in a Power BI report?
Use a simple indicator for each dataset, alongside the figures that depend on it, with a short explanation and an owner. You can do this manually with a text box, but that relies on someone updating it. Automation works better: have your checks update a status table in the semantic model and display it at the top of the report.
How does a user know whether a report is reliable?
Only if the report tells them. A certification badge tells you that someone has approved the report, not that today's data is sound. For that, you need an up-to-date quality status.
Who should be warned about a data quality issue?
The data team, so they can fix it, and the readers of reports that depend on the affected data, so they do not base decisions on it. Most organisations only take care of the first.
Which data quality checks are useful for business users?
Checks that a reader understands: is the data up to date, is it complete, are the values within a reasonable range. Technical checks are useful for the data team, but translate them into one of those questions before showing them to the reader.
Should you show users every data quality issue?
No. Only show issues that change what a figure means. Too many warnings have the same effect as none: people ignore them.