Art of Adoption

Status: In development
Roadmap ID: 569208
Current target as of 1-9-2026: October 2026

Don’t let the title fool you with the previous post, cause…Yes! This is the feature that has generated much of the recent community discussion.

According to various sources I scouted across the internets, Microsoft has added a roadmap item that says users will be able to create HTML with Copilot in SharePoint or upload HTML from another source. The HTML itself will be stored in the Pages library, rendered as a page, and managed alongside SharePoint pages. As of the day of writing (1-9-2026) the general availability is currently targeted for October 2026. We’ll see what pops up around that time :).

What does this thingy do?

At first glance at all the presented info, this sounds very similar to the interactive HTML reports already available through Copilot. However, there is an important difference to be spotted across all the posts and messages, so here’s the breakdown as far as I understand:

• Today’s Copilot-generated HTML can behave as a generated report or file.

• The roadmap feature describes HTML being treated and rendered as a SharePoint page type in the Pages library. So…just like a Newspost is a page type.

That means that it could make HTML content part of the normal publishing lifecycle, rather than just another file sitting in a document library. What immediately comes to mind for me, is that little comment I made somewhere on linkedin about “why isn’t there any lifecycle policy to regulate and auto clean-up pages?” haha, but maybe one day that solution will arrive as well.
For now, let’s look at….

Practical impact for end users

I think…Potentially…that users will gain far more freedom in how information is presented. I am by no means a HTML-expert, but I can think of shiny thingies like

• Project and portfolio dashboards

• Visually rich management reports

• Custom internal landing pages

• Interactive guidance

• Data-driven visualizations

• AI-generated microsites or campaign pages

And that would mean this could provide a middle ground between standard SharePoint page authoring and fully custom SPFx development (of which, I for one, unfortunately have no knowledge). So yeah, I think being enthusiastic about this is a possibility, particularly when HTML pages can be generated using Copilot or automation.
It can translate a knowlegde and expertise gap between people who want visual (like marketing or communication), who are quite often responsible for content but can’t really customize as much as they would visibly please.

But… there’s some parts we don’t know yet (or I have overlooked) 🙂 

Looking at the Microsoft roadmap entry, it does not currently tell us:

• Whether JavaScript will be supported

• Which HTML elements will be sanitized

• Whether inline or external CSS will be allowed

• How external resources are handled

• Whether HTML pages fully support SharePoint publishing and approval

• How branding will be enforced

• What accessibility validation will exist

• How versioning and page analytics will behave

• Whether uploaded HTML receives the same security restrictions as generated HTML

Microsoft has also not stated that the existing restrictions around custom script are being removed. Shout out here to MVP Ryan Clark, who specifically warned against interpreting the HTML roadmap item as a reversal of SharePoint’s custom-script security direction. Look him up 🙂

Unto some: Practical impact for admins

Like I mused here not far above…I think this feature could lower the barrier to custom-looking content. That is useful, but lowering a barrier also means more people can step over it. Do…do we admins like that? So I delved even deeper and…yeah…Maybe, before enabling broad use, consider defining:

• Who may upload HTML

• Who may generate and publish AI-created HTML

• Which sites may contain this page type

• Whether HTML pages require approval

• Which external domains and resources are acceptable

• Minimum accessibility and branding requirements

• A support model for pages that users generate themselves

• Retention, ownership, review, and deletion rules

I guess…once again…can we come up with a way to automate content cleanup and ownership on page-level? 🙂

What I think if you implement this

Do not build production architecture around this feature yet. Sounds weird, I like building architecture, but…just wait a bit.

Instead of immediately trying to kick down the door on this…

1. Add roadmap item 569208 to your change-management watchlist.

2. Test it in Targeted Release when it appears with a good pilotgroup or with your admins.

3. Inspect the resulting files and page behavior.

4. Test permissions, versioning, search, retention, accessibility, mobile rendering, and external sharing.

5. Determine whether scripts, forms, external calls, and embedded content are blocked or sanitized.

6. Publish an organizational guideline before opening it to all page authors.

7. Don’t think you’re done after 6… Implement user adoption all across the board… you know what? Make this number 7 your number 2 and start informing people right away. Communication is key 😀

So yeah, as usual cheesy little outro: The ability to upload HTML may look like a creative black belt. Until Microsoft documents the security boundaries, treat it as a white belt with great potential.

Stay tuned for more!