Your interactive HTML report is going into SharePoint. Two walls it will hit.

The roadmap entry is short: create HTML with Copilot in SharePoint or upload your own, store it in the pages library, render it as a page, share it with your audience. Entry 569208, Targeted Release, expected around October 2026.

If your team makes client-facing reports as self-contained HTML — increasingly the default output when the report came out of an AI tool — that entry reads like the end of a problem. The file finally has somewhere to live that IT already blesses.

Before you route deliverables through it, two things are worth knowing. Both are documented today, both are deliberate, and neither is the kind of thing that gets fixed in a later release, because in both cases the behaviour is the feature.

Wall one: the script doesn't run, and the exception expires

SharePoint blocks custom script by default, and the default is broad. Microsoft's documentation: SharePoint "doesn't allow script on most sites that administrators create by using the SharePoint admin center and on all sites that are created by using the New-SPOSite PowerShell command", and "the same restriction also applies to OneDrive, sites that users create themselves, modern team and communication sites, and the root site for your organization."

That is not an oversight. The docs are equally clear about why: "If you allow custom script, all users who have Add and Customize Pages permission to a site or page can add any script they want." In a tenant holding everyone's documents, that is a large door, and Microsoft keeps it shut.

For an ordinary document this is invisible. For an AI-generated report it splits the artifact in half. The styled layout, the headings, the tables, the images — those are markup and they render. The chart that draws itself on load, the filter that re-sorts the table, the tabs, the little calculator your analyst was proud of — those are script, and they are the reason the deliverable is HTML instead of a PDF. You end up shipping the format's advantages minus the part that made you choose it.

Here's the part that catches people, and it's worth reading twice:

"Changes to allow custom scripts are overridden to Not allowed within 24 hours."

And per-site: "any changes to custom script settings for a specific site last for a maximum of 24 hours. After that time, the setting resets to Blocked for that specific site."

So the sequence that actually happens is: you hit the problem, you raise a ticket, an admin obliges, you test the page, it works, you send the link — and it is broken again by the time anyone reads it. Nothing in your workflow reports this. You wrote a working page, you tested a working page, and the reader got a dead one. The failure is invisible from your side, which is the worst shape a delivery failure can take.

If a document has to behave the same way for the next three weeks, a setting that self-reverts every day cannot be its foundation. That's not a criticism of the setting — a security exception that expires on its own is good design. It just isn't a delivery mechanism.

Wall two: your reader is outside the boundary

The second wall is the one people discover on the client call.

External sharing in SharePoint is configured at two levels, and Microsoft is direct about how they combine: settings exist "at both the organization level and the site level", and "if a site's external sharing option and the organization-level sharing option don't match, the most restrictive value always applies."

Where Microsoft Entra B2B integration is on, the docs say a "guest account always created" when sharing files, folders, or sites. Read that from your client's side: they are not opening a web page. They are being invited into your tenant, authenticating, and landing in a document library UI, where their capabilities are — again per the docs — "limited to basic collaboration tasks" because they have no license in your organization.

Anyone links exist and can genuinely make it one click. Whether they're available on that site isn't usually your call, and they're often restricted for a completely sound reason: the same setting governs the material where unauthenticated access would be a serious problem. Microsoft's own advice is to keep confidential content "in a site that has external sharing turned off" — which is exactly the posture a well-run tenant adopts, and exactly the posture that makes your one report awkward.

None of this is SharePoint failing. It's a compliance boundary doing its job. The thing that doesn't fit is your artifact: a report that needs to run script and open for someone with no account is close to the definition of what the boundary is built to control.

The split that actually works

Don't pick one home. Pick one per job.

SharePoint keeps the record. It's where the deliverable belongs for retention, discovery, and the audit trail — the reasons those defaults exist in the first place. Nothing here argues against that, and if your reader is internal and the report is static, SharePoint alone is fine.

A private link carries the copy that has to work. One URL, scripts intact, opens for someone with no account and no invitation. That's the same split teams already run for an HTML report going to a client, and it's why senior teams increasingly send a link rather than an attachment — not because the internal system is bad, but because the internal system's correct behaviour and an outside reader's expectations point in opposite directions.

One caveat worth stating plainly: HTML pages in SharePoint hasn't reached general availability, and how the pages library interacts with the custom script policy specifically isn't something Microsoft has documented yet. That interaction could turn out better than the current rules imply. What won't change is the second wall — the external reader is governed by external sharing settings regardless of what file type the page is. Plan around that one now, and re-check the first when the feature actually lands.

Microsoft's documented behaviour above was checked against Microsoft Learn on 2026-08-15. Platform policy changes; confirm on their docs before you build a process on it.