SharePoint and OneDrive both run on the same underlying storage, but they’re built for different jobs — SharePoint for shared team/organizational content, OneDrive for individual work. Mixing them up is the most common source of “why can’t my team find this file” complaints.
In this post: What happens when someone leaves · Under the hood, OneDrive is a SharePoint site · SharePoint best practices · OneDrive best practices · When would you actually use this?
What happens when someone leaves
This is the real reason the SharePoint-vs-OneDrive distinction matters, not just findability. SharePoint content stays accessible to anyone with permission regardless of who created it or whether they still work there — the file just keeps the original creator’s name in its metadata. OneDrive content is time-limited: when an account is deleted, the manager gets automatic access for a default 30-day window to move anything important out (to their own OneDrive or a SharePoint site) — after that, without action, it’s gone. A project’s working files living in someone’s personal OneDrive is a real business continuity risk, not just an inconvenience.
Under the hood, OneDrive is a SharePoint site
This explains a lot of the overlap between the two: every user’s OneDrive is, technically, its own SharePoint site collection, provisioned from a personal-site template the first time they access OneDrive. That’s why the same admin center manages both, why the same REST/PnPjs APIs work against a user’s OneDrive as against any other SharePoint site, and why permission concepts (sharing links, external access settings) behave identically in both places. The practical difference is entirely about storage allocation and intended use, not the underlying platform: OneDrive gets its own per-user storage (1TB base, extendable per license, separate from the shared SharePoint site-storage pool covered in Managing SharePoint Storage Limits), while regular SharePoint sites draw from that shared tenant-wide pool.
SharePoint best practices
- Organize with metadata, not deep folder trees — folders don’t scale, views and metadata do.
- Turn on version history for an actual audit trail and the ability to revert.
- Use SharePoint groups for permissions, not individual grants.
- Automate the repetitive parts — approvals, notifications, archiving — with Power Automate.
- Use Hub Sites to connect related sites instead of leaving them isolated.
OneDrive best practices
- Keep it for individual work — team content belongs in SharePoint, not scattered across personal OneDrives.
- Use Files On-Demand to avoid local storage bloat — files stay in the cloud until actually opened.
- Install the sync client for offline access rather than manually downloading/uploading.
- Be deliberate about external sharing permissions — this is the most common accidental-leak vector.
- Clean up periodically — old files accumulate quietly.
Team content belongs in SharePoint, not scattered across individual OneDrives — that’s the single most common cause of “why can’t anyone else find this.”
When would you actually use this?
- A file only one person can find, because it’s sitting in their personal OneDrive instead of a team library — that’s the SharePoint-vs-OneDrive line, made concrete.
- You’re deciding where a new working document should live — if more than one person needs it, SharePoint; if it’s yours alone (for now), OneDrive.
- External sharing needs to happen and you want to avoid an accidental leak — review permissions deliberately rather than accepting the default link type.
Hope it helps — shout in the comments if you get stuck.
App Catalog Authentication Automation Backup Compliance Content Type CSS Flows Google Javascript Limitations List Metadata MFA Microsoft Node NodeJs O365 OneDrive Permissions PnP PnPJS Policy PowerApps Power Automate PowerAutomate PowerPlatform PowerShell React ReactJs Rest API Rest Endpoint Security Send an HTTP Request to SharePoint SharePoint SharePoint List SharePoint Modern SharePoint Online SPFX SPO Sync Tags Teams Termstore Versioning