Microsoft 365 Automation

Why Can't Microsoft 365 Copilot See Your Files or Emails?

Last updated 19 August 2026 · 7 min read

Direct Answer

Copilot's failure to find a file or email it should be able to see is almost always one of a handful of specific, checkable causes, not a general reliability problem: a licence that hasn't finished propagating (which can take longer than expected after assignment), the file simply not being indexed yet by SharePoint or OneDrive search (new or recently moved files can take time to appear), the user genuinely lacking permission to the file (Copilot only shows what the signed-in user could already see themselves — it never bypasses existing permissions), the file living outside Microsoft 365 entirely (a local-only file, a non-Microsoft cloud drive, or a file share Copilot was never connected to), an unsupported file type or an oversized file, or — less commonly — a deliberate IT policy (Restricted Content Discovery, a sensitivity label, or an Information Rights Management restriction) that intentionally keeps specific content out of Copilot's results. Working through these in order, from most to least common, resolves the great majority of "Copilot can't see this" reports.

Detailed Explanation

Copilot's file and email grounding failures read as mysterious mainly because the failure is silent — Copilot doesn't say "I found three files but I'm not allowed to show you two of them" or "your licence hasn't finished activating"; it just answers as though the missing content doesn't exist, or gives a noticeably thinner answer than the user expected. That silence is what makes this a genuinely common troubleshooting question, distinct from the Excel-focused Copilot capability questions this cluster otherwise covers: the problem here usually isn't a limit on what Copilot can do, but a specific, checkable reason it can't currently see the content it needs.

Working through the causes below roughly in order of likelihood resolves most cases without needing to escalate to IT.

The Most Common Causes

A licence that hasn't finished propagating. Assigning a Copilot licence to a user doesn't grant access instantly in every case — propagation can take longer than expected, and a user working across a personal and a work/school Microsoft account on the same device can also trigger access confusion that looks identical to a missing licence. Signing out and back in, or refreshing the licence from within an Office app (File > Account > Update License, then restarting the app), resolves this in most cases.

The file hasn't been indexed yet. Copilot's file grounding relies on the same underlying SharePoint and OneDrive search index the rest of Microsoft 365 uses — it doesn't scan files fresh on every request. A file created or moved moments ago may genuinely not be indexed yet; this typically resolves within minutes, though it can occasionally take longer under heavy system load. If a file still isn't found well after a reasonable wait, the cause is more likely one of the others below.

Permissions the user was never going to have. This is the single most important thing to understand about how Copilot behaves: it only surfaces content the signed-in user could already access on their own. It doesn't have any elevated visibility, and it doesn't bypass SharePoint or OneDrive permissions in either direction. If a file genuinely isn't shared with the user asking about it, Copilot correctly can't see it either — this isn't a bug, and the fix is the same as it would be without Copilot: request access to the file itself.

The content lives outside Microsoft 365 entirely. Copilot's standard grounding covers Microsoft 365 content — SharePoint, OneDrive, Outlook, Teams — plus anything an administrator has explicitly connected via a Microsoft Graph connector. A file sitting only in a personal Dropbox or Google Drive, on a local hard drive that was never synced, or on an old-style network file share that was never connected, is invisible to Copilot by design, not by malfunction.

Unsupported file type or an oversized file. Copilot's file processing has practical limits on format and size that shift as the product updates; a file in an unusual or legacy format, or one that's unusually large, can fail to process even though the user can see and open it normally in its native app.

A deliberate IT policy restricting discovery. Where an organisation has configured Restricted Content Discovery on a SharePoint site, applied an Information Rights Management restriction, or set a Microsoft Purview sensitivity label that excludes a document from AI processing, Copilot is intentionally prevented from grounding on that content — even for a user who could otherwise open the file directly. This is usually deployed to manage oversharing risk (see the related oversharing question below), so if a specific site or document category consistently doesn't show up in Copilot results, check with whoever manages the Microsoft 365 tenant before assuming it's an error.

Email-Specific Grounding Issues

Copilot in Outlook has its own reported pattern where a search that returns complete results directly in Outlook returns only a partial set through Copilot — commonly reported with high mailbox volumes or complex search terms. Where this happens, cross-checking with a direct Outlook search remains the reliable fallback, and treating a Copilot email answer as a starting point rather than an exhaustive one is sensible practice regardless of the specific cause, which continues to be refined as the product updates.

A Practical Troubleshooting Order

  1. Confirm the user can open the file or email directly, outside Copilot, first. If they can't, this isn't a Copilot problem — it's a permissions or account problem that needs solving on its own terms.
  2. Wait and retry once if the content is genuinely new or was just moved, to rule out an indexing delay.
  3. Check the licence status — sign out and back in, and refresh the Office app licence if the account has recently changed.
  4. Confirm the content is actually inside Microsoft 365, not a non-Microsoft cloud service or an unconnected local location.
  5. Check the file type and size against current supported formats if everything else checks out.
  6. Ask the Microsoft 365 admin whether a discovery or sensitivity policy is in play, if the pattern is consistent across a whole site or document category rather than one file.

Things to Consider

  • This is the mirror-image problem to Copilot oversharing, and the two shouldn't be diagnosed the same way. See how do you stop Microsoft 365 Copilot from surfacing files employees shouldn't see for the reverse problem — tightening access to fix that one can, if done without care, create exactly the grounding gaps this page describes for legitimate users.
  • A consistent, sitewide pattern points to policy; a one-off points to indexing or licensing. If Copilot never finds anything from a specific SharePoint site for anyone, that's a strong signal of a deliberate discovery restriction rather than an individual account issue — worth raising with IT directly rather than repeatedly retrying.
  • This behaviour changes as Microsoft updates the product. Copilot's grounding architecture, supported file types, and indexing behaviour have all shifted meaningfully since launch and continue to; treat any specific limit mentioned here as current as of when this page was last reviewed, not a permanent constraint.

Common Mistakes

  • Assuming a missing result means Copilot is unreliable rather than investigating the specific cause. Nearly every "Copilot can't see this" report traces back to one of a small number of checkable causes — treating it as random undermines trust in a tool that's usually working as designed.
  • Escalating to IT before confirming the user can access the file directly at all. A genuine permissions problem needs to be fixed at the SharePoint or OneDrive level regardless of Copilot, and starting there avoids wasted troubleshooting time on the wrong layer.
  • Retrying the same prompt repeatedly when the real cause is permissions or file type. Retrying only resolves the indexing-delay cause — for every other cause, the same prompt will keep failing until the underlying issue (licence, access, file type) is actually fixed.
  • Not distinguishing a personal OneDrive issue from a shared SharePoint site issue when reporting the problem to IT. The likely cause and the fix differ meaningfully between the two — being specific about where the file lives speeds up diagnosis considerably.

Frequently Asked Questions

Is this the same problem as Copilot showing files an employee shouldn't see?
No — it's the opposite problem, and mixing the two up leads to the wrong fix. This page covers Copilot failing to find or use a file it should legitimately be able to access. How do you stop Microsoft 365 Copilot from surfacing files employees shouldn't see covers the reverse: Copilot correctly following existing (often overly broad) SharePoint and OneDrive permissions and surfacing content a specific employee technically has access to but shouldn't. Fixing one doesn't fix the other — tightening permissions to solve oversharing can, if done carelessly, create exactly the access gaps this page describes.
Does re-typing the same prompt eventually fix a grounding failure?
Sometimes, but only for one specific cause: search-index freshness. A newly created or recently moved file can take some time — commonly minutes, occasionally longer under heavy load — before SharePoint or OneDrive search has indexed it, and Copilot draws on that same search index to find content. Waiting a few minutes and retrying quickly confirms or rules out that specific cause. If the file still isn't found after a reasonable wait, the cause is more likely permissions, licensing, file type, or an admin policy — none of which resolve themselves by retrying.
Can Copilot see files stored in Google Drive or Dropbox?
Not by default, and generally not without a specific, deliberately configured connector. Microsoft 365 Copilot's standard grounding covers content inside Microsoft 365 itself — SharePoint, OneDrive, Outlook, Teams — plus any Microsoft Graph connectors an admin has explicitly set up to index outside content. A file that only exists in a non-Microsoft cloud service or a purely local folder is invisible to Copilot unless it's been deliberately connected, which is a meaningful practical limit to plan around rather than a fault to troubleshoot.

References

Related Questions