What’s new in Copilot in SharePoint: October 2026

Hi julieseto​ 

In relation to Copilot in SharePoint. As you know, we raised these issues in an earlier Microsoft post but wanted to highlight them again here as we're still seeing these behaviors following the General Availability of Copilot in SharePoint almost a month ago.

These issues are becoming even more important given the upcoming November 1 rollout of Copilot in SharePoint across all sites. This broader rollout won't adhere to the staged rollout approach some customers have been using.

With the potential exposure increasing so significantly, it's important that these core issues are addressed or that customers are given clear guidance on their resolution.

Auto-fill overwriting version history

This issue was raised several times during testing, months before General Availability, and initially we were advised that it had been resolved. Unfortunately, our current testing indicates that the issue still persists.

When Autofill updates metadata, we've seen it effectively overwrite the latest version history entry rather than create a new version. This makes it difficult to accurately track, and audit changes made to a document's metadata.

There is also an associated issue with the Modified date and time. Because Autofill appears to overwrite the latest version rather than create a new version, the document can retain its previous Modified date even though Autofill has subsequently changed its metadata.

For example, if a user modifies a document three days ago and Auto-fill changes its metadata today, the document can still indicate that it was last modified three days ago. From an auditability perspective, this makes it very difficult to determine when the metadata was actually changed.

For organizations that rely on accurate version history and auditability, this remains a significant concern.

The screenshots we've captured demonstrate version 3.0 being overwritten by Autofill, with the Modified date remaining unchanged, including the removal of the previously entered Review Date. On the left is before, and the right is after.

We would strongly recommend customers validate this behavior in a test library before deploying Autofill more broadly.

Multiple versions created during a single Autofill processing run

This issue was also raised months ago during testing and remains an important consideration when multiple Autofill columns are configured.

This applies to a list/library having multiple Autofill columns configured. Rather than the metadata updates being processed together as a single transaction, individual Autofill column updates can potentially generate separate versions. This means a single processing event can result in multiple additional versions of the document.

This has two important implications:

• Version history can become unnecessarily cluttered and more difficult to audit. Where an organization has configured a limit on the number of versions retained, these additional Auto-fill-generated versions could also cause older, potentially more meaningful versions to be removed from the retained version history sooner than expected.
• Storage consumption can potentially increase because each additional version represents another version of the file.

At enterprise scale, particularly across large document libraries, this could result in unnecessary storage consumption and significant associated costs.

Ideally, Autofill would process all configured metadata updates together and generate a single new version, while preserving the previous version and accurately updating the Modified date and time.

No support for files within folders

This was another major limitation identified and raised months ago during testing, including by multiple customers during the Early Access Program.

Currently, Autofill only processes files at the level where it's run. Where a document library contains folders or subfolders, files within those folders aren't processed unless users navigate into each folder and run Autofill separately.

For organizations with structured document libraries containing multiple levels of folders and subfolders, this significantly limits where Autofill can be practically used.

In our environment, this limitation would exclude the majority of our existing document libraries from practical use with Autofill.

Ideally, Autofill should support processing content recursively across a document library, including files contained within folders and subfolders, without requiring users to navigate into and process each folder individually.

It would be great if Microsoft could provide an update on these issues.

Given the scale of this change, it would be helpful to understand the current status of these issues, whether fixes or improvements are planned, and the expected timelines. These aren't simply feature enhancements. They affect core areas such as version integrity, auditability, storage consumption, and the practical ability to use Autofill across existing enterprise document libraries.