Microsoft Flow Is Now Power Automate: What Automating Internal Communication Does to Your Numbers

By Nicolas Saliba · 8 min read

Somebody in IT built a flow in 2023 that reposts every new SharePoint news item into forty Teams channels. Nobody told the internal communication team. That quarter, reported reach rose by roughly a third, the team was congratulated for a campaign redesign that had nothing to do with it, and the following quarter the flow was switched off during a channel clean-up. Reach fell back. The team spent a fortnight explaining a decline it had not caused.

This is the everyday reality of automation in internal communication, and it is not an argument against automating. It is an argument for treating every flow that touches a communication channel as a change to the measurement baseline, because that is exactly what it is.

The rename, and why the old name still matters

Microsoft Flow became Power Automate several years ago. The capability did not shrink, it grew: cloud flows, desktop flows and business process flows now sit under one banner^[1]. But the old name persists in two places that matter. It survives in intranet documentation written before the change, and it survives in what people type into search when they want to automate something in SharePoint. If a colleague asks you about “the Flow that sends the newsletter”, they mean a Power Automate cloud flow, and the distinction between flow types is worth knowing because it determines what you can trigger and what you can log^[2].

The flows internal communication teams actually run

Set aside the demo scenarios. In a 12,000-person organisation on Microsoft 365, the flows that touch communication almost always fall into four groups.

Approval routing. A news item drafted on a communication site goes to a named approver before publishing. This is governance, not distribution, and it has no direct effect on your numbers beyond slowing or accelerating time to publish.

Cross-posting and notification. A published item is announced into Teams channels, a Viva Engage community, or by email. This is the group that changes your numbers, and it is the group nobody documents.

Forms to list to action. A Microsoft Forms response lands in a SharePoint list, triggers a task, and sends a confirmation. Useful for feedback loops and event registration, and quietly valuable for measurement because it produces a structured record with a timestamp.

Scheduled digests and reminders. A weekly roll-up assembled from a list and pushed to a channel or mailbox. Reliable, cheap, and the most common source of notification fatigue in organisations that have several of them running in parallel.

Automated notification inflates reach and not attention

This is the part that gets missed. When a flow announces every new article into forty channels, the number of people who could have seen a link to the article goes up sharply. The number of people who read it does not move in proportion, and after a few weeks it often moves down, because a channel that receives an automated post every day trains its members to scroll past that shape of post.

The consequence is a reporting distortion that is easy to describe and awkward to admit. Delivery went up. Opportunity to see went up. Read depth stayed flat or fell. If your monthly slide reports reach, the automation looks like a success. If it reports read depth and downstream action, the automation looks like noise. Both readings come from the same fortnight.

The discipline that fixes this is not complicated. Separate four quantities and never let them collapse into one: delivered, surfaced, opened, and read to completion. Automation reliably improves the first two. It has no mechanism for improving the last two, and it can degrade them. Our note on internal communication KPIs sets out how to present the four without inviting the wrong conclusion.

Flow type	What it genuinely improves	What it inflates	The metric to watch
Cross-post to Teams channels	Speed and consistency of announcement	Impressions and apparent reach	Click-through per surfaced post, over time
Email notification on publish	Delivery to people who never visit the intranet	Delivered counts	Open and read depth, by segment
Scheduled weekly digest	Predictable rhythm, lower editorial load	Send volume	Sustained open rate after week eight
Viva Engage auto-announcement	Community awareness of new content	Community activity counts	Replies and unique participants, not posts

Automation belongs in the measurement pipeline, not only the publishing one

Most teams point Power Automate at distribution and stop there. The more interesting use is to point it at your own reporting problem, because the hardest part of internal communication measurement is not counting activity, it is knowing what each piece of activity was supposed to do.

Three flows repay the effort immediately. The first writes a row to a SharePoint list every time a news item is published, capturing the intended audience, the campaign, the owner and the surfaces used. That list is the denominator record your analytics will need later, and it costs nothing to maintain once it is automatic. The second stamps campaign metadata onto items at publish time so a message that runs across the intranet, a community and the newsletter can be reassembled into one campaign afterwards, which is the precondition for any cross-channel measurement. The third logs the flow inventory itself: which automations are live, what they touch, and when they were changed.

That third one sounds bureaucratic and is the one that saves a quarter. When reach moves 30 per cent and nobody can say why, the flow register answers the question in a minute.

The honest case for native reporting, and for Power BI

Microsoft 365 admin activity reports are free, already switched on, and adequate for questions about product usage^[3]. If you want to know whether Teams message volume rose after you introduced a digest flow, that is answerable natively and you do not need anything else. What the native reports will not do is tell you whether the rise happened among the population the digest was written for, because they do not join to organisational attributes.

The usual next step is a Power BI build over the Microsoft Graph reporting API^[4]. It can be made to work and it is harder than it looks. The reporting API is not consistently reliable and produces days with missing data. Customers have observed KPI values in Power BI that do not reconcile with the native SharePoint reports for the same period. A dependable build needs a robust ingestion process, scheduled reconciliation against the native figures, and a named owner. Budget for the pipeline rather than the dashboard. Automation makes this sharper rather than easier, because a flow that changes publishing behaviour mid-quarter puts a discontinuity in a series that the dashboard will render as a smooth trend.

A governance rule worth adopting this month

One rule covers most of the damage. Any flow that posts to a communication channel, sends to a distribution list, or writes to a communication site is registered, owned by a named person, and dated. When it is created, changed or retired, the date goes in the register and the register is read at the start of every quarterly review.

Gallagher’s State of the Sector research consistently finds measurement to be the capability internal communicators name first as missing^[5]. A surprising share of that gap is not analytical at all. It is that nobody in the organisation holds a list of what is currently automated. The teams that keep one can explain their own trend lines, and the teams that do not spend their review meetings speculating.

This is where a measurement layer earns its place. Tryane reads SharePoint, Viva Engage, Teams and your newsletter platform together, joins that activity to your organisational structure through Entra ID or an HR file, and keeps history across tooling changes so a step change caused by a new flow is visible as a step change rather than absorbed into a smooth line. It is SOC 2 Type 2 certified and GDPR compliant by design, hosts in the EU by default with US data residency on request, deploys in a couple of hours with single sign-on through Entra ID, and installs no agent. If Copilot is also in the picture, the companion piece on measuring internal communications with Copilot in the mix covers the same problem from the AI side, and the note on newsletter metrics beyond open rate is the natural next read if your automation is mostly email.

Frequently asked questions

Is Microsoft Flow the same thing as Power Automate?

Yes. Microsoft Flow was renamed Power Automate, and the product then expanded to cover desktop automation and business process flows alongside the original cloud flows. Documentation, tutorials and internal wiki pages written before the change still use the old name, which is why the term persists inside organisations long after the branding disappeared.

Will automating our announcements improve engagement?

It will improve consistency and speed, and it will raise the number of people who are given the opportunity to see a message. Whether it improves engagement depends entirely on whether the automated post is distinguishable from the other automated posts arriving in the same channel. Where several flows publish into the same space, the usual outcome is that all of them are ignored equally.

How do I stop automation from distorting our reporting?

Keep delivered, surfaced, opened and completed as four separate numbers, date every automation change in a register, and annotate your trend lines when a flow goes live or is retired. Most reporting distortions caused by automation are not measurement failures. They are undocumented changes to the thing being measured.

Can Power Automate collect the data we need for measurement?

It can collect the context that analytics tools cannot infer: the intended audience, the campaign name, the owner, the surfaces used and the publication timestamp. It is not an analytics tool and will not tell you who read what. Used as a metadata capture mechanism at publish time, it makes everything downstream considerably easier.

Do we need a licence beyond Microsoft 365 to run these flows?

Standard cloud flows using SharePoint, Teams, Outlook and Forms connectors are generally covered by Microsoft 365 licensing, while premium connectors and some capacity limits require additional licensing. Check the current Power Automate limits and configuration guidance before designing anything that runs at high frequency across a large tenant.