Copilot in SharePoint Just Got Live Dashboards and One-Click AI Buttons

What shipped

The August 2026 release of Copilot in SharePoint added two capabilities that change what a SharePoint page can do, plus a model update worth knowing about.

1. Interactive dashboards that stay live

Copilot can now turn a SharePoint list, an Excel file, or a CSV into an interactive dashboard — and critically, the dashboard stays connected to the underlying data. It refreshes from the source whenever it is opened, rather than freezing a snapshot at creation time.

This is the detail that matters. Static, AI-generated charts have been available in various forms for a while, and they consistently rot. A chart that was accurate the day it was generated and silently wrong three weeks later is worse than no chart, because people keep trusting it. A dashboard that re-reads its source on open is a fundamentally different reliability proposition.

2. AI page buttons

Site owners can now place one-click AI actions directly on SharePoint pages. A page button holds a saved Copilot prompt; a visitor clicks it and the prompt runs.

The practical use cases are immediate:

• "Summarize the policy changes in this library since last quarter"
• "Draft a project status update from the entries in this list"
• "Explain this dataset's columns in plain language for a new team member"
• "Flag any items in this list that are past their review date"

The pattern here is the promotion of prompting from an individual skill to a site capability. Until now, getting value out of Copilot in SharePoint depended on each user knowing what to ask. A page button lets the person who understands the content author the question once, on behalf of everyone who will ever visit that page.

3. New frontier models

Two frontier models became selectable in Microsoft 365 Copilot: OpenAI's GPT-5.6 and Anthropic's Claude Opus 5. For most SharePoint scenarios the model choice is not the constraint — content quality, permission hygiene and prompt clarity dominate the outcome — but for organizations doing heavier summarization and reasoning over large document sets, it is worth testing both against your own corpus rather than assuming.

---

Why the "stays connected" part is the real story

Consider how a typical SharePoint list gets reported on today:

• Someone exports the list to Excel
• They build a chart
• They paste the chart into a page, a deck, or an email
• The underlying list changes
• Nobody updates the chart
• Decisions get made on a stale picture

Steps 4 through 6 are the entire problem, and they are so routine that most organizations have stopped noticing them. A dashboard that re-reads its source on open removes steps 4 through 6 structurally rather than through discipline.

That is worth more than it initially sounds. Most reporting failures in SharePoint environments are not analytical failures — they are freshness failures.

---

Where this fits against Power BI

We get this question immediately whenever Microsoft ships visualization into a surface that is not Power BI, so let us be direct:

| | Copilot dashboards in SharePoint | Power BI |

|---|---|---|

| Built by | The person who owns the list | BI team or trained analyst |

| Data scope | A list, Excel file, or CSV | Modeled datasets across many sources |

| Governance | Site permissions | Semantic model, row-level security, workspace lifecycle |

| Best for | Fast in-context answers on operational data | Governed enterprise reporting |

| Licensing | Copilot licensing | Power BI licensing |

These are not competitors. Copilot dashboards are for the operational middle — the list of open risks, the project tracker, the equipment inventory, the intake queue — where the question is "what does this look like right now" and the audience is the team that owns the data.

The practical effect worth planning for: this will absorb a meaningful share of the low-complexity report requests that currently land on BI teams. That is a benefit, but only if you route it deliberately. Announce it. Tell people that operational list reporting is now self-service, and that Power BI intake is for governed, cross-source, or externally-facing reporting. Otherwise you get both — Copilot dashboards proliferating *and* the same request volume hitting BI.

---

The governance work this creates

None of this is a reason to hold the features back. It is a reason to sequence them.

Permissions come first

Copilot in SharePoint respects permissions. A user who cannot read a list cannot get a dashboard of it. That is the correct model and it is worth stating plainly, because the concern gets raised in every rollout conversation.

The real risk is different and less discussed: Copilot converts theoretical access into practical access. Content that a user was technically permitted to read, but that was buried five levels deep in a library nobody navigates, is now one prompt away from being surfaced and summarized.

Every organization has this content. Site collections inherited from a migration, libraries with broken inheritance, nested groups that granted more than anyone intended, the "Temp" folder from 2019 that someone shared with Everyone. All of it was always readable. It was just never findable.

Run a permissions audit on your highest-traffic sites before a broad Copilot enablement, not after. Nested group expansion, broken inheritance, and anything shared with organization-wide scopes are the priorities.

Page buttons are published content

A saved prompt on a page that hundreds of people click is not a personal shortcut. It is content, and it deserves the same review a published page gets.

The failure mode is subtle. It is rarely data leakage — permissions still hold. It is that a poorly framed prompt becomes the default interpretation of a dataset for everyone who uses the button. "Summarize the risks in this register" and "Summarize the *critical* risks in this register and note anything overdue" produce meaningfully different institutional behavior, and the second one is only there if somebody thought about it.

Recommended practice:

• Site owners may author buttons on their own sites
• Buttons on hub sites, intranet landing pages, and anything above a traffic threshold get reviewed before publish
• Maintain an inventory of published buttons with an owner and a review date
• Re-review when the underlying content structure changes

Dashboards inherit source data quality

A live dashboard over a list with inconsistent choice values, half-populated columns, and three different date formats will faithfully and continuously visualize that mess. Connected data does not mean clean data. Lists that are about to become dashboards are lists worth tidying first.

---

A sensible rollout sequence

Weeks 1–2 — Audit. Permissions review on your top sites by traffic. Resolve broken inheritance and organization-wide shares. Establish what is actually exposed before you make it discoverable.

Weeks 3–4 — Pilot. Two or three sites with clear content ownership and known-good permissions. Let site owners build dashboards and buttons. Watch what they build — it will tell you more about your governance gaps than a policy document will.

Weeks 5–6 — Standards. Write the button review process. Publish guidance on what makes a good saved prompt. Define the boundary between Copilot dashboards and Power BI intake and communicate it to both audiences.

Week 7 onward — Widen. Expand by site tier, with permissions verified ahead of each wave. Keep the button inventory current from the start rather than reconstructing it later.

---

Our read

The dashboards feature is the more substantial of the two. Live-connected visualization built by content owners, with no modeling step and no separate licensing conversation, addresses a real and chronic gap — the operational reporting layer that was always too small to justify Power BI and too important to leave as a stale Excel chart.

The page buttons are the more interesting one long term. Moving prompting from an individual skill to a site capability is a structural change in how organizations get value from Copilot, and it favors organizations with strong content ownership. If your sites have clear owners who understand their data, buttons will compound. If your sites are orphaned and your permissions are a decade of accumulated exceptions, buttons will mostly surface that.

Which is, as usual with SharePoint, less a story about the new feature than about the environment you are turning it on in.

---

Planning a Copilot rollout and unsure whether your permissions will hold up? See SharePoint & Copilot, or get in touch — a permissions and readiness assessment before enablement is considerably cheaper than an oversharing incident after it.

Sources

• What's New in Copilot in SharePoint: August 2026 — Microsoft Community Hub
• Microsoft Copilot in SharePoint Gets Interactive Dashboards and AI Buttons