You show Great Expectations results to business users by translating them out of the data team's tooling and into something readers already see. There are three common routes: share the Data Docs that Great Expectations generates, write the results to a status table your Power BI report reads, or send alerts to the channel where the business works. Whichever you pick, add plain wording, a named owner and what the failure means for the number on screen.
At a glance
- Data Docs are useful, but their expectation-level detail often suits the people who wrote the tests better than the people reading the report.
- A business user needs to know three things: is today's number fit to use, what's wrong in plain words, and who is fixing it.
- A practical way to reach report readers is a small status table that your reports read, accompanied by a named owner for each dataset.
Why test results rarely reach the people reading the report
Many data teams treat the job as done once the tests run. It isn't. A failed expectation that only the data team sees gives the person reading the report no warning.
For example: on Tuesday morning a check on the orders table fails because a source file arrived half empty. The data engineer sees it in the validation results. The sales manager opens the weekly report at nine, sees a dip in orders and starts asking the team why.
In practice, the result exists. It just lives in a place the business never opens, in words the business doesn't use.
Option 1: Share Great Expectations Data Docs
Great Expectations documents Data Docs as static, human-readable documentation built from your Expectations and validation results. You can host them as a static site so readers with the appropriate access can see which checks passed and which failed.
That's a good start for analysts. For business users it's often too much. A page listing expectations by column name doesn't tell a finance manager whether this month's revenue figure is safe to present. If you go this route, link only the summary pages and add one plain sentence per dataset on what a failure means.
Option 2: Write results to a status table your Power BI report reads
This route puts the result directly in front of the report reader. After each validation run, write a small record per dataset to a table in your warehouse: dataset name, status, time of the run, a plain-language message and the owner. This is a custom implementation you build, not a native Great Expectations connector to Power BI.
Then add that table to the semantic model and show it on the report: a status card on the first page, or a line in the header that says when the data was last checked and whether it passed. Coordinate the status update with the report's refresh so the warning reflects the data readers are viewing.
- Keep it short. One status per dataset, not one per expectation.
- Write the message for the reader. “Orders from the web shop are incomplete for yesterday” beats “expect_column_values_to_not_be_null failed”.
- Name the owner. A reader who sees a warning needs to know who to ask.
The trade-off: you build and maintain it yourself, for every report that needs it.
Option 3: Send alerts where the business already works
Great Expectations Checkpoints can perform Actions after validation, such as updating Data Docs or sending notifications. Configure a supported notification Action or a custom integration for your chat or email destination. Point the alerts for business-critical datasets to the channel that report owners actually read, not only to the data team's channel.
Alerts work well for urgent failures. They work less well as a visible record: a message from Tuesday can be buried by Thursday, and someone opening the report later may not see it.
What business users actually need from a quality result
Whatever route you choose, check the result against three questions a reader would ask.
- Can I use this number today? A clear yes, no or “with care”, not a percentage of passed checks.
- What's wrong, in my words? One sentence about the business impact, not the test.
- Who is fixing it? A named person, not “the data team”.
Comparing the options
| Route | Who sees it | Where | Effort to maintain | Reaches the report reader |
|---|---|---|---|---|
| Data Docs | Analysts and data engineers | A separate static site | Low once generation and hosting are configured | Only if they open the site |
| Status table in the report | Report readers | On the Power BI report | Medium, built and maintained by your team | Directly, when included in the report and kept current |
| Alerts to a channel | Whoever is in the channel | Chat or email | Low once set up | When they notice the message |
| A catalog that gathers quality issues | Business users and owners | One overview, next to definitions and owners | Depends on the tool and available integrations | Through a catalog or marketplace, if readers use it and results are available there |
A practical framework: Test, Translate, Route, Show, Own
- Test: keep running Great Expectations where it runs today. The testing location does not need to change.
- Translate: write one plain-language sentence for what each failure means to the business.
- Route: decide per dataset where the result goes: a status table, a channel, or both.
- Show: put a simple status where readers look, with the time of the last check.
- Own: give every business-critical dataset one named owner who answers questions about it.
Start with five business-critical datasets
Great Expectations helps tell the data team what broke. A validation result alone does not tell the sales manager whether to trust Monday's report. That translation is your job: plain words, a named owner and a status where readers already look. Start with the five datasets your management reports depend on.
Frequently asked questions
How do I show Great Expectations results in Power BI?
Build a custom process that writes a summary of each validation run to a table in your warehouse, one row per dataset with status, time and a plain message. Add it to your semantic model and show it as a status card or header line on the report. Keep the status aligned with the report's data refresh. This is an implementation you maintain, not a native connector.
Can business users read Great Expectations Data Docs?
They can open them if they have access, but Data Docs are static documentation organised around expectations and validation results, which suits the people who wrote the tests. Most business users need a single status and a sentence about impact, so add a summary layer if Data Docs are your only route.
How do I alert business users when a data quality check fails?
Use Checkpoint Actions to send a notification after validation, with a supported notification Action or custom integration for your destination. Send alerts for business-critical datasets to a channel report owners actually read. Keep the message in business terms and name who is fixing it.
Should data quality results be shown on every report?
No. Start with the reports that feed decisions: management, finance and board reporting. Showing a status on every report can turn into noise that readers ignore.
Who should own a data quality issue that business users see?
One named person per dataset, usually the business owner rather than the engineer who wrote the test. The engineer fixes the pipeline. The owner tells readers whether the number can be used.