SharePoint document management: the complete guide for Microsoft 365 teams

SharePoint is Microsoft's document management and collaboration platform – the place where files, folders and shared knowledge actually live in a Microsoft 365 organisation. Most teams use a fraction of what it can do. They store files in it the way they used to store files on a network drive, and wonder why collaboration is still awkward.

The problem is usually not SharePoint itself. It's that SharePoint gets deployed without a plan. Files get dumped into a default document library. Folders get nested five levels deep. Nobody agrees on naming conventions. Search stops returning useful results. Within a year, the environment is harder to navigate than the shared drive it replaced.

This guide covers how to use SharePoint properly: how document libraries work, how to organise files so people can actually find them, how permissions should be structured, how SharePoint integrates with Microsoft Teams, what the platform's limits are, and how to handle archiving without creating a new kind of mess.

What SharePoint document libraries actually are

A document library is the core unit of SharePoint storage. It looks like a folder in a file explorer, but it isn't one – and that distinction matters.

A document library is a list. Every file in it is a list item, which means every file can carry metadata: columns that describe the file's department, project, status, client, or any other attribute you define. Unlike a folder path – which can only encode one dimension of context at a time – metadata lets you categorise a file along multiple axes simultaneously and then filter or sort by any of them.

Libraries also have versioning built in. Every time a file is saved, SharePoint can retain the previous version, with a full history of who changed what and when. This is not a backup system – it's a living audit trail embedded in the library itself.

Permissions live at the library level by default, but can be set at the folder level or even the individual file level if needed. A single site can host multiple libraries, each with its own permission set, which is how you isolate sensitive content (HR files, finance data) from general team files without needing separate sites.

Finally, document libraries sync to the desktop via the OneDrive sync client. Files in SharePoint can appear in File Explorer on Windows or Finder on macOS, behaving like local files – but stored in the cloud and available to everyone with access.

→ Getting started with SharePoint document libraries: a beginner's guide

File organisation in SharePoint

The most common mistake when moving to SharePoint is replicating a traditional folder hierarchy and calling it done. This approach works in the short term and fails in the medium term – and it fails for the same reason network drives always failed: folders encode only one dimension of structure, and reality has more dimensions than that.

Folders still have a role

Folders are not wrong. They're useful when there's a genuinely hierarchical relationship between items – project phases, financial years, geographic regions. The mistake is using folders as the only organisational layer, and especially using them to encode things that would be better expressed as metadata.

A folder called "2024/Q3/EMEA/Approved" works until someone needs to find all approved documents regardless of year. Then the structure collapses, and the answer is "search for it" – which only works if naming conventions have been followed perfectly.

Metadata as the primary layer

The better pattern is metadata-first organisation. Instead of nesting files in folders, you add columns to the library: Year, Quarter, Region, Status. Any combination of values can then be surfaced as a view – effectively a saved filter – that behaves like a folder without being a folder.

Microsoft 365 also supports content types: reusable templates that define which columns apply to a particular kind of document. A "Contract" content type might carry Client, Expiry date, and Responsible solicitor; a "Project brief" content type might carry Project code, Sponsor, and Phase. Content types can be shared across sites via the Content Type Hub.

Naming conventions

Even with good metadata, file names matter. A file called v3_FINAL_FINAL_use this one.docx is a symptom of a process problem, but it's also an indexing problem – it's difficult to search for and impossible to interpret without context.

A consistent naming convention – agreed across the team and enforced through templates where possible – reduces noise and improves findability. A typical pattern: [Project code]_[Document type]_[Version]_[YYYYMMDD].

→ Best practices for file organisation in SharePoint

Permissions and access control

SharePoint's permission model is powerful and, if poorly understood, can become a source of both security problems and usability frustration.

How permissions cascade

Permissions in SharePoint flow from the site downward. By default, a document library inherits the permissions of the site it lives in. Folders inside the library inherit the library's permissions. Individual files inherit the folder's permissions.

At each level, you can break inheritance and set unique permissions – but this should be done sparingly. Every time you break inheritance, you create a permission boundary that future administrators need to track and audit. Organisations that break inheritance liberally end up with permission structures that nobody fully understands.

Keep it simple: groups over individuals

The most sustainable approach is to manage permissions through Microsoft 365 groups rather than assigning permissions directly to individual users. A group called "Marketing team" has members; the group has permissions on the site. When someone joins or leaves the marketing team, you change their group membership – not their site permissions.

Direct user permissions ("I've shared this file with sarah.jones@example.com") should be reserved for external sharing scenarios, not routine internal access control.

Site members, visitors, and owners

Every SharePoint site comes with three default permission groups:

• Owners: full control, including the ability to change permissions and delete the site
• Members: can add, edit and delete files; cannot change permissions
• Visitors: read-only access

For most team sites, the majority of users should be Members, with a small number of designated Owners. Visitors is appropriate for stakeholders who need to read reports but should not be able to modify content.

External sharing

SharePoint supports sharing files and folders with people outside your organisation via shareable links. Before enabling external sharing, your IT administrator should define the scope: can anyone with the link access the file, or only specific named external users? Can files be downloaded, or viewed only? These settings are configured at the tenant level in the Microsoft 365 admin centre, and can be overridden at the site level.

SharePoint and Microsoft Teams

Most Microsoft 365 teams use Teams as their daily working environment. What they often don't realise is that every Teams channel is backed by a SharePoint document library – and understanding this relationship is key to making both tools work well.

How Teams creates SharePoint structure

When you create a new Microsoft Teams team, a SharePoint site is automatically created in the background. The General channel maps to a "General" folder in the default Documents library. Each additional channel you create generates a corresponding folder. Private channels go further: they get their own separate SharePoint site with their own permission boundary.

This means every file shared in a Teams channel is stored in SharePoint. Teams is the interface; SharePoint is the storage layer.

Managing the Teams–SharePoint relationship

Because Teams creates SharePoint structure automatically, it's easy to end up with a SharePoint environment that mirrors an overly complex Teams architecture – dozens of channels, each with its own folder, none of them well-organised.

The better approach is to plan the Teams channel structure deliberately, because it directly determines the SharePoint folder structure. Fewer, well-named channels produce a cleaner document library. If you find yourself with a library full of poorly named channel folders, that's a signal to rationalise your Teams structure rather than try to reorganise SharePoint independently.

→ How SharePoint document libraries integrate with Microsoft Teams folders

OneDrive vs SharePoint: which one to use

OneDrive is personal cloud storage – your digital desk drawer. SharePoint is shared team storage – the office filing system. The distinction sounds simple, but it gets muddled in practice, with real consequences for access control, collaboration, and offboarding.

What goes in OneDrive

OneDrive is the right place for:

• Work in progress that isn't ready to share
• Personal templates and reference documents
• Files you'll eventually move to SharePoint once they're ready for team use

Files in OneDrive are owned by you. When you leave the organisation, your OneDrive content is owned by your manager or IT, and eventually deleted. If team files live in your OneDrive, they're at risk when you leave.

What goes in SharePoint

SharePoint is the right place for everything the team needs to access, collaborate on, or find:

• Project documentation
• Shared templates and forms
• Contracts, proposals, and client-facing materials
• Reference content that multiple people need to read and update

Files in SharePoint belong to the site, not to an individual. People come and go; the content stays.

The sync confusion

The OneDrive sync client syncs both OneDrive files and SharePoint document libraries to the desktop. This is useful, but it means that files appearing in File Explorer under "OneDrive – Company" might actually be SharePoint files – they're just synced via OneDrive. The storage location (SharePoint vs OneDrive) is separate from the sync mechanism.

→ If you're using OneDrive for collaboration, you're doing it wrong

Version control and co-authoring

Two of SharePoint's most valuable document management features are also the most underused: versioning and real-time co-authoring.

How versioning works

When versioning is enabled on a document library (it is by default on modern SharePoint sites), every save creates a new version. You can see the complete history of a file – who changed it, when, and what it contained at each point – and restore any previous version with a single click.

Libraries support major and minor versions. Major versions (1.0, 2.0, 3.0) are typically used to mark significant milestones – draft complete, reviewed, approved. Minor versions (1.1, 1.2, 1.3) track incremental edits in between. You can configure whether minor versions are visible to all members or only to editors, which is useful for draft documents that shouldn't be circulated until approved.

Versioning history is not a substitute for formal backups, but it eliminates the most common everyday catastrophe: overwriting a file by mistake.

Co-authoring in real time

Modern Office files (Word, Excel, PowerPoint) stored in SharePoint support simultaneous editing. Multiple people can have the same document open at the same time, see each other's cursors and changes, and avoid the classic "please close the file so I can edit it" problem.

Co-authoring requires files to be stored in SharePoint or OneDrive (not on a local drive or a network share), and requires users to open files through a browser or a modern version of the Office desktop apps. Files opened in "compatibility mode" (older formats like .doc rather than .docx) do not support co-authoring.

SharePoint as a network drive replacement

Teams migrating off legacy file servers frequently ask whether SharePoint can replace a network drive. The answer is yes – but with caveats that are worth understanding before you start, because a failed migration is more disruptive than not migrating at all.

What works

The OneDrive sync client makes SharePoint feel like a network drive. Files appear in File Explorer, can be opened directly in desktop applications, and edits save back to SharePoint automatically. For most everyday file access, the experience is comparable to a mapped network drive – and usually faster, since CloudFront-like CDN edge caching means files load from a server close to the user.

SharePoint also supports offline access. The sync client caches files locally, so you can work on them without an internet connection and they sync when connectivity is restored.

Where the limits are

Path length: SharePoint enforces a 400-character URL limit. Deep folder hierarchies with long names can hit this limit, causing sync failures. Files migrated from a network drive with long paths often need to be reorganised before they can be added to SharePoint.

File types: Certain file types are blocked from upload – executable files (.exe, .bat), and some others that pose security risks. Files with characters in their names that are valid on Windows but not in URLs (such as # or %) also cause problems.

Sync client limits: The OneDrive sync client has a practical limit of around 300,000 files across all synced libraries. Libraries with very large numbers of small files can cause sync performance problems.

→ Can SharePoint be used like a network drive for file storage?

Understanding SharePoint's limits

SharePoint Online is not infinitely scalable in every dimension. Knowing the limits before you hit them prevents problems that are expensive to fix retroactively.

The 5,000-item list view threshold

This is the limit that catches teams most off guard. When a document library (or SharePoint list) contains more than 5,000 items, SharePoint restricts which views can be displayed without applying a filter. Unfiltered views of large libraries stop loading, and users see an error.

The fix is architectural: use indexed columns, apply filtered views by default, and – if needed – introduce folder structure to keep individual folders under the 5,000-item threshold. Libraries with sensible metadata and appropriate views rarely trigger this limit in practice, but libraries used as dump-all repositories often do.

Storage limits

Each Microsoft 365 tenant gets a baseline of 1TB of SharePoint storage, plus 10GB per licensed user. Individual site collections can be configured up to 25TB each (though tenant-wide limits still apply). Individual files can be up to 250GB.

URL length

The combined length of the site URL, library name, folder path, and file name cannot exceed 400 characters. This is rarely a problem for new deployments but frequently a problem when migrating from network drives with deep folder hierarchies.

List and library limits

A single SharePoint site can contain up to 2,000 lists and libraries (combined). Individual lists can hold up to 30 million items, subject to the view threshold above.

→ Understanding SharePoint Online's large list and library limits

Search and findability

One of SharePoint's most cited frustrations is search. When it works, it's powerful – full-text indexing across all your files, with relevance ranking, refiners, and preview. When it doesn't return the right results, it erodes trust in the entire platform.

Why SharePoint search underperforms

Search quality in SharePoint is directly proportional to metadata quality. A library full of files named Document1.docx, Final_v3.docx, and Use_this_one.docx with no column values set will return poor search results regardless of how good the search engine is.

Consistent file naming, populated metadata columns, and accurate document titles (set in the document properties, not just the file name) all improve search quality significantly.

Microsoft Search vs SharePoint Search

Modern Microsoft 365 tenants use Microsoft Search – a unified search experience that spans SharePoint, Teams, Outlook, and other Microsoft 365 services simultaneously. When a user searches from the SharePoint start page, the Microsoft 365 home page, or Bing with work account, they're using Microsoft Search.

Microsoft Search learns from usage. Files that are opened frequently by a given user, or shared frequently within a team, surface higher in results. This means search quality improves naturally as the platform is used – provided the content is organised to begin with.

Improving findability without touching search settings

The most effective findability improvements are content changes, not search configuration changes:

• Enforce consistent naming conventions for file names and library column values
• Use content types with required fields so files can't be saved without key metadata
• Create saved views that surface the most commonly needed subsets of a library
• Train users to use the file name and the Title column (the Title column is indexed and searchable separately from the file name)

Archiving strategies

Files don't go away. Projects end, clients leave, compliance obligations stack up, and the content that was active two years ago is now just noise in the search index.

A deliberate archiving strategy separates active from inactive content, keeps the working environment clean, and ensures that material is retained – or deleted – according to defined rules rather than inertia.

Retention labels and Microsoft Purview

Microsoft 365 includes Purview compliance tools that allow retention labels to be applied to content – either manually by users or automatically based on content type, keywords, or metadata values. A retention label can instruct SharePoint to:

• Retain the file for a specified period before allowing deletion
• Delete the file automatically after a specified period
• Mark the file as a record (preventing modification)

Retention labels are the right approach for regulated industries where document retention periods are defined by law (financial records, healthcare records, legal correspondence). For most organisations, simpler manual archiving processes are sufficient.

A practical two-step approach

For teams without formal compliance requirements, a practical approach is:

Step 1 – Move to a staging area: When a project closes or content becomes inactive, move the relevant folder to a designated "For archiving" folder within the same site. This removes it from the default view without deleting anything.

Step 2 – Periodic bulk archive: On a schedule (quarterly, annually), move the contents of the "For archiving" folder to a dedicated archive site or document library. The archive site can have more restrictive permissions (read-only for most users), reduced storage costs, and a separate search scope so it doesn't pollute active search results.

→ Folder archiving strategies for Microsoft 365 & SharePoint

Further reading

If you're using SharePoint alongside monday.com, the complete guide to Microsoft 365 SharePoint integration with monday.com covers how the two platforms connect – automated folder creation, document generation, Excel sync and embedded file views.