A report counts twelve requests while a new dashboard shows ten. Before looking for arithmetic errors, ask whether one counts created requests and the other completed requests. Both may be correct under different definitions. An unexplained difference turns a decision meeting into an argument about the number.
When commissioning business intelligence dashboards, ask the provider to explain each metric's route from source to screen. Visual design is part of delivery, alongside definitions, sources, a data model, refresh behavior and permissions that can be reviewed. Matching an attractive screenshot is insufficient.
Start with a metric serving a decision-maker
A fictional service company receives twelve requests during a week. By review time, ten are complete and two cancelled. Operations wants completed work, while intake staff want incoming requests. Do not choose one number and label the other wrong. Name both metrics and define their cutoff and included states.
| Example metric | Definition for the fictional sample | Expected value |
|---|---|---|
| Incoming requests | The twelve requests created in the specified week. | 12 |
| Completed within that cohort | Requests in the same group marked complete at review time. | 10 |
| Cancelled within that cohort | The two requests in that group cancelled at review time. | 2 |
This demonstrates definitions rather than prescribing a metric for every business. You may instead count requests by completion date, including work started in a previous week. That is another definition to document, rather than an invisible formula change.
A small card for each core metric
Request a card a business manager can read: name, purpose, included and excluded records or states, date field, aggregation method, source and definition approver. Add a small example that can be calculated manually and explained.
Record the effect of branch, period and service-type filters. If an order number repeats across a file containing multiple order lines, ask how the model avoids counting it repeatedly when the requirement is to count orders. Data grain should not be an assumption the developer makes alone from a file's appearance.
What arrives alongside the dashboards?
- Source register: Systems, files and tables used, their access owner and known limitations.
- Metric definitions: Approved cards and the decisions behind each definition.
- Data model: Relationships, core transformations and the grain represented by records.
- Quality log: Missing, duplicate or inconsistent values and who corrects the source or approves an exception.
- Refresh plan: How new data arrives, its timing, failure monitoring and ownership.
- Usage and handover guide: Permissions, files, accounts, tests and the process for changing a metric.
Microsoft's modeling guidance explains the importance of relationships and grain for filtering and aggregation. You need not design the model yourself, but the provider should explain why a number appears and how selecting another branch or period changes it.
Refreshing a visual does not establish fresh source data
Ask what happens when a user clicks refresh and when the source was last read. Power BI documentation distinguishes storage, connection and refresh approaches. “Real-time” therefore needs a testable explanation in the proposed solution.
For the fictional service company, change a request status in the test environment and observe when it appears under the agreed plan. Also test an unavailable source: is the last refresh time visible, who receives an alert and how does a user recognize stale data? Reopening a page should not make an old number look new.
Test permissions through the user's account
If a branch manager should see only that branch, demonstrate it with the proposed accounts, filters, navigation and in-scope exports. Hiding a branch name from a menu alone is insufficient evidence of controlled data access.
Identify who adds users, changes roles and grants editing or sharing rights. Separate reporting-tool and cloud licences from model and dashboard development fees. Publishing and viewing requirements differ; check the chosen plan and actual charges instead of a general promise of unlimited access.
An acceptance session returning to the data
Choose a sample with known results. Fix the definition, period and branch, then reconcile the value with the source. Follow the agreed route from totals to explanatory records. Change one filter at a time and record the reason for differences instead of changing data to match a chart.
Review an incomplete or duplicate case from the quality log, a new refresh and a restricted user. This does not prove permanent quality across every record. It demonstrates that definitions, implementation and review mechanisms work for the agreed sample. Ongoing error tracking belongs in operation.
For data gathered across systems, the integration discovery guide can expose missing inputs. Commission business dashboards and analytics with the metric card and deliverable list, so you know what to review before choosing a chart style.
Modeling and refresh sources
Microsoft's guidance on star schema and semantic models and data refresh was opened on 3 November 2026. No connection mode or licence is assumed suitable for every project. Numbers belong to a fictional example. The explanation was prepared with AI assistance and review of its content and sources.
