How to Create an Internal Communication Report in Power BI That Holds Up

By Nicolas Saliba · Published December 2025, Updated August 2026 · 8 min read

The monthly communications review is where a Power BI report gets tested. Fourteen visuals, a date slicer, a site slicer, a card at the top with total page views. The CCO looks at the intranet number, nods, then asks whether the safety campaign reached the plants or only the offices. The report cannot answer that, because nothing in the model knows what a plant is. No amount of formatting will fix it.

This article is about the decisions that come before the first visual: what belongs on the monthly slide, what grain the model needs to support it, and where a Power BI build on Microsoft 365 data goes wrong in ways that only surface in front of an executive audience. If you are still choosing a connection method, our guide on how to analyse SharePoint with Power BI covers the plumbing, and the honest guide to SharePoint analytics in Power BI covers what to expect from the data. Here we assume data is already arriving.

Design the slide before you design the model

Almost every internal communication report in Power BI is built in the wrong direction. Someone connects to whatever the Microsoft 365 admin reports and the Graph reporting API hand over, sees which fields exist, and builds visuals of those fields^[1]. The report ends up shaped by the API rather than by the conversation it has to survive.

Invert it. Before you open Power BI Desktop, write the five or six sentences you want to say out loud in the review. Real ones, in business language:

“The safety campaign reached 71 per cent of manufacturing and 94 per cent of head office. Last quarter the gap was twice that.”
“News readership in Germany fell for the third consecutive month. It held everywhere else, so this is not a platform problem.”

Each sentence is a specification. The first requires reach as a rate, which requires a denominator, which requires a population count per segment, which requires an audience dimension that Microsoft 365 activity data does not carry. The second requires country plus a trend that outlives the native retention window. Write the sentences and you have written the data model brief.

The four questions a monthly report has to answer

The same four questions come back every month, and each breaks the model in a specific, predictable place.

Question	Measure it implies	Grain the model needs	Where it usually breaks
Did it reach the people it was written for?	Unique readers in a segment divided by the population of that segment	One row per person, item, channel and day, joined to an audience dimension	There is no population denominator anywhere in the tenant data
Is attention holding or decaying?	Repeat visits, read completion or dwell time on a rolling twelve months	Item-level daily facts retained beyond the native reporting window	The native window truncates the trend exactly when you need it
Which channel actually landed?	Unique people reached per channel, de-duplicated across channels	A single person key shared across SharePoint, Viva Engage, Teams and email	Each source carries its own identifier and they do not join cleanly
Is this getting better?	The same measure, defined identically, month over month	Frozen measure definitions with a change log	Definitions get quietly edited between months and nobody records it

The model behind the slide

Get the grain right, once

The most expensive mistake in these builds is aggregating too early. If your pipeline lands daily view counts per site, you have thrown away any answer to “how many distinct people”, because distinct counts do not sum. Three visits by one person and one visit by three people produce the same number after aggregation, and they mean very different things to a communications team.

Land facts at the grain of person, item, channel, date, and aggregate in the measure layer. It costs storage. It is also the difference between a report that answers follow-up questions and a report that produces a second meeting.

The audience dimension is the one that matters

Everything useful in an internal communication report comes from the join between activity and organisational structure: a person dimension sourced from Entra ID or an HR extract, carrying function, country, site, language, contract type and whether the person is deskless. Microsoft 365 gives you the activity. It does not give you this, and this is where the analysis lives. Our note on audience segmentation for internal communications covers how to structure those attributes before you start modelling.

Two governance points, neither optional. Agree with HR and, in France, with the works council which attributes may be used for communications reporting. Then set a minimum segment size in the model itself, so no visual can render a group small enough to identify an individual. A report that drills to a named person stops being a communications report and becomes something your legal team has a view on.

Keep the measure list short as well. Ten well-defined measures beat sixty, named in the language the CCO uses rather than the language of the API, with a definitions page in the report file recording each formula, its source and the date it last changed.

The part nobody puts in the project plan

A Power BI build on Microsoft 365 data is not a dashboard project. It is a data pipeline project with a dashboard at the end, and the pipeline is where the effort goes^[2]. Three things are worth knowing before you commit.

First, the Microsoft Graph reporting API is not consistently reliable. It produces days with missing data. In a line chart a missing day does not announce itself, it just makes a dip, and a dip is something a communications team will spend an afternoon explaining before discovering there was nothing to explain^[3].

Second, customers have observed KPI values in Power BI that do not reconcile with the native SharePoint reports for the same period. Not wildly different, which would be easy to spot, but different enough that an executive with both open will ask which one is true. That question, asked once in a steering committee, has ended more of these projects than any technical failure.

Third, a dependable build therefore needs a robust ingestion process and a scheduled reconciliation against the native figures, with a named owner. Budget for the pipeline rather than the dashboard. The visuals are two days of work; the ingestion, retries, deduplication, identity mapping and monthly reconciliation are the actual project.

One detail catches teams late: the Microsoft 365 admin centre has a privacy setting that conceals user, group and site names in all reports, replacing them with pseudonymised identifiers. If your tenant has it switched on, and many regulated organisations do, the person-level join does not work until it is turned off with the appropriate approvals. Check in week one, not month three.

Put reconciliation on a page

The teams whose Power BI reports survive have all done the same unglamorous thing: a data quality page inside the report, left visible. Rows loaded per source per day, with any zero-row day flagged. A variance line comparing your reach figure against native SharePoint site analytics for a control set of pages^[4]. The date of the last successful refresh, in large type.

It catches silent failures before the review rather than during it, and when a number is challenged you open the page instead of promising to look into it.

What actually goes on the monthly slide

One slide, with everything else in an appendix that nobody will open but that has to exist. The slide carries the headline reach rate against target, the same figure broken by the two segments that matter this month rather than all twelve, the direction of travel over six months, and one sentence of interpretation written by a human. That sentence is the part that gets you invited back. Our guide to executive reporting for internal communications goes further on framing, and the monthly reporting template gives you a structure to start from.

When Power BI is the right build, and when it is not

Power BI is the right answer more often than vendors admit. If your scope is one channel, your question set is stable, you have a data engineer with capacity and the licence is already paid for, build it and own it.

It is the wrong answer when the internal communication team ends up owning the pipeline. That works until the person who built it changes role, at which point the report degrades quietly for two quarters before anyone notices. It is also the wrong answer when the scope is genuinely cross-channel: the identity mapping across SharePoint, Viva Engage, Teams and your newsletter platform is the hardest part of the exercise, and Power BI will happily let you postpone it. Our piece on measuring cross-channel internal communications sets out what that join involves.

Tryane sits in that second case: it reads those channels together, joins activity to organisational structure through Entra ID or an HR file, keeps history across product transitions, and pushes the resulting model back into Power BI if that is where your organisation looks. You keep the front end and stop maintaining the pipeline. Practically: SOC 2 Type 2 certified, GDPR compliant by design, EU hosting by default with US data residency on request, single sign-on through Entra ID, deploys in a couple of hours, no agent to install. For campaign-level return on investment specifically, the note on internal campaign ROI in Power BI is the closer read.

Frequently asked questions

How long does a Power BI internal communication report take to build?

The visuals take days. The pipeline takes months, because it needs two or three reconciliation cycles before anyone trusts the numbers. A three-week timeline is quoting the dashboard, not the data.

Can I get reach as a percentage without an HR file?

Not reliably. A percentage needs a denominator, and Microsoft 365 activity data tells you who did something, not how many people could have. Entra ID gets you part of the way if department and country are well populated, but contract type, site and deskless status usually come from the HR system. Without a denominator you are reporting volume, and volume does not answer the executive’s question.

Why do my Power BI numbers differ from the SharePoint page analytics?

Several causes at once: different deduplication rules, different handling of service accounts, different time zone boundaries, and days where the Graph reporting API returned nothing. Customers have repeatedly observed values that do not reconcile with the native reports for the same period. The fix is not to hunt for the one true number, it is to publish a documented definition, reconcile on a schedule, and show the variance openly.

Should the internal communication team own the Power BI model?

Own the measure definitions and the slide. Do not own the ingestion. When communications owns the pipeline, maintenance competes with campaign work and loses. Give IT or the data team the refresh, the retries and the monitoring.

Does Tryane replace Power BI?

No. Many customers keep Power BI as the presentation layer and use Tryane as the measurement layer feeding it, which removes the ingestion and reconciliation burden while leaving reports where the organisation already looks. Native Microsoft reporting keeps doing what it does; Tryane adds the cross-channel join, the organisational segmentation and the history that survives product transitions.

Sources

• Microsoft Learn, Microsoft 365 activity reports

• Microsoft Learn, Power BI overview

• Microsoft Learn, Microsoft Graph reporting API

• Microsoft Learn, SharePoint portal health and site analytics