Quick answers
Why does this matter? Claude accesses your M365 documents through Microsoft Graph API, which relies on metadata and search indexing, not folder browsing. Most SharePoint sites are built for humans clicking through folders, not AI querying for content.
What should you do? Flatten your document libraries, add structured metadata columns, keep files under 65 pages, and create a shared AI Assets folder synced through OneDrive for Cowork access.
What is the biggest mistake? Leaving your ten-levels-deep folder hierarchy untouched and expecting AI tools to work through it the way your team learned to over the last five years.
Every organization I talk to about Claude deployment hits the same wall around week three. The pattern that keeps showing up: setup goes fine, week one looks brilliant, then complaints land in week three and nobody can explain why.
The initial setup goes smoothly. IT enables the M365 Connector, somebody with Global Admin rights approves the permissions in Entra ID, and the team starts asking Claude questions about their documents. Then the complaints start. “It cannot find the Q3 report.” “It gave me last year’s version.” “It says it does not have access to the file I am looking at right now.”
The problem is not Claude. The problem is not the connector. The problem is that your SharePoint site was built for humans who know which folder to click, and AI does not click folders. What annoys me about most M365 rollouts is the way document layout never gets a second thought.
Reorganizing SharePoint and OneDrive for Claude to find your documents is one half of this. The other half is designing the CLAUDE.md hierarchy that governs what Claude does once it has access to those documents. The two sit on the same SharePoint structure but use different loading mechanisms - the M365 Connector indexes file content via Microsoft Graph, while Claude Code walks parent directories looking for CLAUDE.md files. If you are about to roll either pattern out across teams, design both at the same time so they share a single canonical source.
Two companion posts cover the CLAUDE.md side: a two-level hierarchy with a seven-check audit for the design discipline, and the four-track deployment that gets one canonical CLAUDE.md to every Claude surface for the plumbing. Read them in that order if you have not started yet, in reverse if you already have a hierarchy that needs unpicking.
How does the M365 Connector actually work?
The M365 Connector for Claude is available across all Claude plans, from Free to Enterprise. It connects through Microsoft Graph API with delegated permissions, meaning Claude sees exactly what each user can see. Nothing more. No admin backdoor, no special access. Read-only across SharePoint, OneDrive, Outlook, and Teams.
A Global Admin in your Entra ID tenant needs to approve the connection once. After that, individual users authorize their own access. The permissions are scoped to the user, not the organization. This is important because it means your existing SharePoint permissions structure determines what Claude can and cannot retrieve.
Here is where the architecture matters. Wait, before I go further, the metadata-versus-folders distinction is the whole point and worth being clear on. When Claude searches for a document through the connector, it is not opening folders and browsing file lists the way you do. It is querying Microsoft Graph, which returns results based on metadata, search indexing, and content signals. If your documents have no metadata, inconsistent naming, and live eight folders deep in a hierarchy that only makes sense to the person who created it, the query returns rubbish. Or nothing.
Metadata-first document architecture
Here’s where it gets messy for teams used to running everything through folder structures. The single most impactful change you can make is shifting from folder-based organization to metadata-based organization. Turns out, Microsoft’s own SharePoint best practices documentation recommends this anyway, but most organizations never make the switch because folders feel familiar.
Flat document libraries with rich metadata columns outperform deep folder structures for both human and AI access. Which sounds obvious, but almost nobody does it. The practical ceiling is roughly ten columns per library before management overhead exceeds the benefit. Start with these five:
Department is the column that replaces your top-level folder structure. Instead of Finance/Reports/Q3/2025/, you have a single Reports library with a Department column set to Finance.
Document Type replaces the second level of folders. Report, Policy, Template, SOP, Contract, Proposal. Pick categories that match how people actually ask for documents, not how your filing system evolved over the years.
Status matters more than most teams realize. Draft, Active, Archived, Superseded. Without this column, Claude has basically no way to distinguish your current operating procedures from the version you abandoned two years ago. It will happily surface the old one if it matches the query better.
Last Verified Date is the column nobody thinks to add until they realize their AI assistant is citing a compliance document from 2019. Set a review cadence. Update this field when someone confirms the document is still current.
AI-Ready is a yes/no flag you set after confirming a document meets the formatting requirements for AI consumption. More on those requirements below.
Does every document need all five columns filled? No. The real answer is most teams cobble together two or three columns to start and add the others over the first quarter. (Which is fine. Better than building all five and never tagging a thing.)
SharePoint autofill columns can handle some of this automatically. The feature uses AI to extract metadata from document content and populate columns without manual tagging. It works well for straightforward document types. For anything requiring judgment, human review still matters.
If your firm needs to move on this, start with a Blue Sheen conversation.
Preparing documents Claude can actually read
Not every document format works equally well for AI processing. A 200-page scanned PDF with no OCR layer is effectively invisible. An image-heavy PowerPoint with no alt text is mostly blank to an AI reading it.
Keep files under 65 pages. This is not a hard technical limit, but processing quality drops noticeably beyond that length. I said “65 pages” above. That oversimplifies it. The real answer is page count is a proxy for token count, and a 30-page document full of dense tables is harder for the model than a 100-page document of plain prose. Treat 65 as a rule of thumb, not a hard threshold. If you have longer documents, split them into logical sections. Your 150-page employee handbook becomes five focused documents that Claude can actually work with.
Naming conventions matter because they affect search ranking. A file called Final_v3_FINAL_updated_NEW.docx tells Claude nothing about its content. A file called Finance-Quarterly-Report-Q3.docx tells it everything. Adopt a consistent pattern across your organization and enforce it through library validation rules.
Proper formatting helps. Documents with clear headings, consistent styles, and structured content process better than documents with messy, ad-hoc formatting. Tables with headers parse better than tables without. Lists with consistent structure are more retrievable than freeform prose.
Scanned PDFs need an OCR layer. SharePoint’s built-in search already handles this for indexing purposes, but the quality varies. For critical documents, run them through a dedicated OCR tool before uploading. The extra step pays for itself every time Claude correctly retrieves a finding from a scanned contract instead of missing it.
Setting up OneDrive sync for Cowork
Claude Cowork operates differently from the M365 Connector. I waffle on this on which one to lead with when explaining this to a team, but the cloud-versus-local distinction trips up most teams the first time. Where the connector queries your cloud documents through Graph API, Cowork runs autonomous multi-step tasks that can search the web, execute code, and work with files. It is available on Pro, Max, Team, and Enterprise plans, and currently runs on macOS and Windows x64.
For Cowork to work with your organizational documents, those documents need to be accessible on the local machine. This is where OneDrive sync becomes critical infrastructure rather than a convenience feature. The decision of where files live for AI matters even more than how they are organized, because SharePoint and OneDrive expose content to AI agents in fundamentally different ways.
Create a centralized folder structure that gets synced to every relevant user’s machine through OneDrive:
A shared Templates folder contains your standard document templates, report formats, and reusable frameworks. When someone asks Cowork to draft a quarterly report, it pulls the current template automatically.
A Reference Docs folder holds your organizational knowledge base. SOPs, product specs, competitive analysis, anything that informs ongoing work. Keep this curated. A reference folder with 500 unorganized files is worse than no reference folder at all. In advisory work with mid-size companies, this is the folder that goes off the rails first because nobody owns it.
A Prompts folder stores your tested, validated prompts for common tasks. This is the piece most organizations skip. Building a shared prompt library that your team actually uses turns tribal knowledge into organizational capability.
A Team Outputs folder is where Cowork deposits its work product. Having a consistent location makes it easy to review, share, and build on AI-generated work.
The OneDrive sync client keeps these folders current across machines without manual effort. Set up the shared library sync once, and every user on the team has the same reference material available locally for Cowork to access.
Can you skip the sync and just point Cowork at SharePoint directly? No. And since this is the corner everyone tries to cut, here is what actually happens, from a live test with an enterprise IT team in June 2026. A SharePoint sharing link returns the viewer page, with its share and print chrome, never the raw file. Forcing a download parameter doesn’t strip it. The direct-download URL trick works only inside a browser that already holds a Microsoft session; an AI tool fetching the same URL gets the Entra sign-in wall instead. OneDrive’s “Anyone” links are the closest thing to a clean fetch, and they expire on a forced schedule, and in any tenant with NIST or cyber-insurance obligations they’re disabled outright. Sync the library locally for Cowork and Claude Code, paste the always-on core into Organization Instructions for chat, and let the M365 Connector retrieve named files on demand under the user’s own auth. Those are the paths that survive a security review. A pasted link is not one of them.
Once your folder structure is in place and synced, the next problem is making one CLAUDE.md instruction file actually load on every Claude session in the company. SharePoint inheritance does not propagate the file itself, and each Claude product reads CLAUDE.md a different way. The 4-track CLAUDE.md propagation architecture covers how to make a single root file land across Claude Code, Desktop, web, and Cowork.
MCP connectors for deeper integration
The M365 Connector handles the common case. That’s not quite right. The M365 Connector handles the common case well enough that most teams do not need to think about MCP at all in year one. For organizations that need deeper or more customized integration with SharePoint, MCP (Model Context Protocol) servers provide a more flexible path.
Dario Amodei’s Anthropic ships several built-in connectors for enterprise environments, and the open-source community has produced additional MCP servers specifically for SharePoint and OneDrive access. These can query SharePoint list data, pull document metadata, and provide structured access to content that the standard connector does not surface.
Enterprise deployment of MCP servers uses .mcpb bundle distribution through your MDM platform. Three control tiers govern what runs on managed endpoints: admin-pushed servers via managed-mcp.json, allowlist and denylist policies for user-installed servers, and desktop extension controls. This layered approach lets IT provide useful integrations while maintaining security boundaries.
The practical use case for custom MCP beyond the standard connector is usually one of two things. Either you need access to SharePoint list data (not just documents), or you need to enforce specific retrieval patterns that match your organization’s information architecture. A custom MCP server can query your metadata columns directly, filter by your AI-Ready flag, and return only current, verified documents.
If your team is already thinking about data privacy implementation for AI tools, MCP governance fits neatly into that framework. Same approval process, same security review, same audit trail expectations.
The Microsoft Copilot Cowork convergence
Satya Nadella’s Microsoft announced Copilot Cowork in March 2026, a new execution layer for Microsoft 365 that uses Anthropic Claude for reasoning within the Microsoft 365 environment.
This is major for document organization because it means the structure decisions you make now will serve double duty. Organizations that get their SharePoint metadata, naming conventions, and document formatting right for Claude’s M365 Connector are simultaneously preparing for Copilot Cowork’s cloud-based document access. The underlying retrieval mechanics are similar: metadata-driven queries through Microsoft Graph, not folder browsing. Same plumbing, different label.
Copilot Cowork runs in your M365 tenant, handles multi-step long-running tasks, and can access your organizational data natively. Unlike Claude’s Cowork which operates on local files, Microsoft’s implementation is cloud-first. Both benefit from the same document preparation: clean metadata, consistent naming, manageable file sizes, and structured content.
I said same above. It is not identical, but the overlap is major.
Organizations that restructure their SharePoint now will be positioned to use both tools effectively from day one. Organizations that wait will hit the same painful wall twice.
Worth discussing for your situation? Reach out.
