Art of Adoption

Status as of 28-08-2026: Recently rolled out through Copilot in SharePoint
Audience: End users, information workers, site owners
Licensing: Microsoft 365 Copilot requirements apply to Copilot-generated experiences

So…what I deduced from the internets, meaning different posts and the Microsoft roadmap, this allows Copilot in SharePoint to generate an interactive HTML report from content stored in SharePoint. Users can then ask it to turn project information, sales figures, or library content into a presentable and interactive report, without manually building a page, Power BI report, or custom application.

Microsoft subsequently expanded this with live SharePoint dashboards. This would be a dashboard generated from a SharePoint list that can remain connected to the underlying list data and refresh when opened. Dashboards can also be generated from Excel and CSV sources. Sounds neat… but

What does this mean in reality? Let’s take a looksie!

 

Practical impact for end users

I think this thing reduces the distance between having data and telling a useful story with that data. So yeah, a project manager could turn a project list into a dashboard showing some neat things like:

• Overall project health
• Upcoming milestones
• Risks and blocked activities
• Budget status
• Ownership and accountability
• Filters by status, department, or priority

Microsoft itself even suggests scenarios such as inventory tracking, recruitment pipelines, application processing, and customer escalations, which…could prove useful in the right situation. Of course, as long as the list data the report is based on is accurate I think that the important distinction here, is that this is not necessarily the same as building a governed Power BI solution. To me, it seems closer to creating a lightweight, interactive presentation layer over existing SharePoint information. Which is especially cool if you need a dashboard, but aren’t familiar with PowerBI.

The admin and site owner side of the story

All good and well on the user part, but what does it imply for an admin, or a site owner. I’ve already mentioned that dashboards are as reliable as the underlying data…So the first one of the list of “keep-this-in-mind is a no-brainer.

1. The dashboard inherits the quality of its source.
   As with all data, quality matters! hahaha. But yeah…If list columns are inconsistent, values are entered as free text, or ownership is unclear, the dashboard may look polished while still presenting unreliable information.
2. Confirm how permissions behave.
   Test whether users can only see data they are already authorized to access, especially when reports combine files, lists, or folders. As is quite often the case with combining apps. Remember the Excels that Forms produce? Yeah, they needed separate permissions as well 😀 This is the same, but even more public and flashy on your SharePoint.
3. Do not confuse presentation with governance.
   An interactive report does not automatically provide certified KPIs, controlled calculations, or formal data ownership. The dashboard shows things, maybe numbers…but who’s responsible for them?
4. Create usage boundaries.
   As always, the “easy road” is isn’t always the best road. Decide when an HTML dashboard is appropriate and when a use case should move to Power BI, Power Apps, or a formally supported SPFx solution.

What if I want to implement this? 

Yeah I’ve been thinking about this as well, good question! I think it’s best to start with a governed SharePoint list that already has some neat things in place like:

• A clear business owner (who’s responsible for the numbers)
• Some defined columns and allowed values (have a purpose and a plan)
• Meaningful views (yeah, views help for users ánd dashboards!)
• A known audience (think about who’s gonna wanna see those numbers)
• A recurring reporting requirement (I mean, do you really need to have a Christmas attendee dashboard up all through Easter?)

To speak in some martial art wisdom: first learn the stance, then add the speed