Today we announced the new Copilot app, bringing together how people assist, delegate, build, and automate work in one experience powered by Work IQ.
Because Work IQ grounds these experiences in yo...
We're incredibly excited about Copilot in SharePoint and see enormous potential in what Microsoft is building. It's something we're actively looking to enable in our environment. However, we're disappointed that several key issues raised during the Early Access Program remain unresolved despite being highlighted months ago.
Below are just four examples, all related to the Auto-fill functionality, that we believe customers should be aware of and which Microsoft should prioritize addressing.
(1) Overwriting Manual Corrections
Auto-fill does a great job in many scenarios, but it isn't always correct. When it extracts incorrect information, users naturally need to manually update the metadata.
The problem is that subsequent Auto-fill runs can overwrite those manual corrections without warning. This creates significant risks where metadata is being used for reporting, compliance, cost allocation, health and safety processes, or other business-critical purposes.
There needs to be a mechanism to either:
Respect manual overrides.
Require approval before replacing a manually edited value.
Provide reporting or auditing that clearly identifies when Auto-fill has overridden a user correction.
Without this capability, organizations may struggle to trust Auto-fill-generated metadata in critical business scenarios.
(2) Overwriting Version History
This issue was raised several times during testing, and we were advised it had been resolved. Unfortunately, our recent testing indicates it still persists.
For organizations that rely on accurate version history and auditability, this is a serious concern.
In our testing, when Auto-fill updated metadata, it not only reverted manual corrections but also effectively overwrote the previous version history entry. As a result, changes made by users became difficult to track and audit because the most recent version was replaced by an AI-generated update.
We strongly recommend customers validate this behavior in a test library before deploying Auto-fill across production content.
There is also another side effect of this behavior. Because Auto-fill appears to overwrite the latest version rather than create a new one, the document retains the original Modified date and time. For example, if a user last updated a document three days ago and Auto-fill runs today, the document can still show it was last modified three days ago even though AI has changed the metadata today. This makes it very difficult to understand when content was actually altered and further undermines the auditability of the solution.
See the screenshots below that show version 3.0 being overwritten by Auto-fill, and Modified date not changing. You can see that it's wiped the Review date entry.
(3) Multiple Versions Created for a Single Processing Run
When multiple Auto-fill columns are configured, the updates don't appear to be processed as a single transaction.
Instead, each column update can potentially generate its own version, meaning a single processing event can create multiple additional document versions.
This has two implications:
Version history becomes cluttered and more difficult to audit.
Storage costs can increase unnecessarily because each version represents another copy of the file.
At enterprise scale, this could have a measurable impact on storage consumption and associated costs. It would be far more efficient if Auto-fill processed all metadata updates together and generated a single version.
(4) No Support for Files Within Folders
This remains one of the biggest limitations we identified during testing and was highlighted by multiple customers during the Early Access Program.
Currently, Auto-fill only processes files at the level where it is run. If a document library contains folders, files located within those folders are not processed unless users navigate into each folder individually.
For organizations using structured document libraries with multiple levels of folders and sub-folders, which remains a very common information architecture pattern, this significantly limits the usefulness of Auto-fill.
In our environment, this limitation would exclude the majority of our document libraries from practical use.
SharePoint Search
In addition, it increasingly feels like Microsoft is treating users without a Copilot license as second-class citizens when it comes to search. Users are now presented with completely different search experiences depending on whether they have a Copilot license, including entirely different user interfaces. There is effectively no longer a unified search experience, something Microsoft used to be very proud of. In our view, all users should receive the same core search experience and user interface, with users who have a Copilot license gaining access to additional AI-powered capabilities such as Search Summaries, Search Result Overviews, and other Copilot-enhanced functionality. This concern applies to both Copilot Search and SharePoint Search (to be confirmed once we see the final implementation). Most organizations have a mix of users with and without a Copilot license, and creating fundamentally different search experiences across the workplace only adds confusion, training overhead, support challenges, and inconsistency for end users.
Search remains one of the biggest barriers preventing broader adoption of SharePoint as a true enterprise knowledge platform. We've been forced to use custom solutions (which we do not want to do) or moved some of our content and business processes outside of SharePoint specifically because of limitations in the current search experience and the lack of mature multilingual capabilities (Multilingual is severely lacking across the board - not just search). That's why we're so passionate about seeing the next generation of SharePoint Search succeed.
Closing Thoughts
To be clear, Copilot in SharePoint is genuinely impressive and has the potential to deliver tremendous value. That's precisely why we're so passionate about providing this feedback.
The foundation is strong, and we absolutely see the benefits. However, addressing these kinds of practical, real-world operational issues would significantly improve customer confidence and help organizations like ours accelerate adoption.
Hi Grant, thank you for your continued support of Autofill and for taking the time to share such detailed feedback. Our PM has already connected with you to better understand your specific scenarios, and these insights are very valuable to us.
We’ve started rolling out overwrite protection, which gives you control to preserve manual corrections when Autofill runs again. Once it’s available in your environment, please let us know how it works for your scenarios and whether it meets your needs.
Several other improvements are on the way, and your feedback is helping shape that work. Thanks again for your continued engagement—please keep the feedback coming and stay tuned for updates!