Overview
A dashboard nobody trusts is worse than no dashboard
The failure mode is not an ugly chart. It is two reports showing different figures for the same metric, nobody able to explain the discrepancy, and the whole reporting layer quietly abandoned in favour of the spreadsheet somebody maintains by hand.
- Defined data modelA documented model with explicit relationships and named measures, so a number means the same thing in every report that uses it.
- Traceable figuresEvery metric traceable back to its source, with the transformation logic documented rather than buried in a query nobody opens.
- Refresh that holds upGateways, scheduled refresh and incremental refresh configured so reports are current without manual intervention.
- Row-level securityAccess controlled at the data level, so the same report shows each viewer only what they should see.
Architecture
A model, not a pile of queries
One fact table, conformed dimensions, single-direction relationships. This is what makes two reports agree on the same number.
What is included
What we build
Data modelling
Star schema design, relationship configuration and DAX measures written to be readable by whoever inherits them.
SharePoint reporting
Reports over SharePoint lists and libraries, including the pagination handling that large lists require.
Executive dashboards
Summary views designed for people who will look at them for ninety seconds, with drill-through for those who want more.
Operational reporting
Detailed reporting for teams who work in the numbers daily, with filters and bookmarks that match how they actually work.
Embedded reporting
Power BI surfaced inside SharePoint pages and Teams, so people do not need to go somewhere else to see it.
Workspace governance
Workspace structure, deployment pipelines and dataset ownership, so reporting does not sprawl the way it usually does.
In practice
Why reporting over SharePoint needs particular care
SharePoint lists are convenient data sources and awkward ones. The connector paginates, large lists throttle, lookup and person columns arrive in shapes that need reshaping, and a list that performs well at two thousand items behaves differently at fifty thousand.
None of this is a reason to avoid SharePoint as a source — for most operational reporting it is exactly the right place for the data to live. It does mean the refresh strategy needs designing rather than accepting the default, particularly where a report combines several large lists.
Where volume genuinely outgrows it, we will say so and propose a staging layer rather than letting refresh times creep up until the report becomes unreliable.
Questions
Common questions
Can you report across SharePoint, SQL and other systems together?
Yes. Combining sources is common and is where a properly designed model earns its cost.
Do we need Power BI Premium?
Not usually. Pro licensing covers most requirements. Premium becomes relevant at larger dataset sizes, higher refresh frequency, or when you need to distribute to unlicensed viewers.
Can reports show different data to different people?
Yes, through row-level security defined in the model, so a manager sees their region and a director sees all of them from the same report.
Can you fix reports we already have?
Yes. We start by reviewing the model, since inconsistent figures almost always trace back to the model rather than the visuals.