A project team says it cannot find the latest proposal. One person opens the Files tab in Teams, another searches SharePoint, and a third has saved a copy in a chat. The issue is rarely Microsoft 365 itself. It is usually that no one has agreed how SharePoint versus Teams files should work in practice.
The short answer is that Teams and SharePoint are not competing file stores. Files shared in a Team are stored in SharePoint. Teams is the collaboration interface people use while they are talking, meeting and working together; SharePoint provides the underlying document management, permissions, version history and structure.
That distinction matters because it changes the question from Which platform should we use? to What type of work and content does this file support?
SharePoint versus Teams files: the practical difference
When you create a Team, Microsoft 365 creates a connected SharePoint site. Files uploaded to a standard channel sit in the Documents library on that site, normally in a folder named after the channel. Opening a file from the Teams Files tab is therefore not bypassing SharePoint. It is simply accessing a SharePoint document library through Teams.
Teams is usually the better front door for active, team-based work. It keeps conversations, meetings, tasks and the files being discussed in one place. If a marketing team is preparing a campaign, or a delivery group is updating a project plan every day, Teams gives people the context around the document as well as the document itself.
SharePoint comes into its own when content needs to outlive a particular conversation or project team. It is better suited to controlled policies, templates, departmental records, published procedures and intranet content. It also gives you more scope to create a clear information architecture, use metadata, define retention requirements and present documents through a well-designed intranet page.
The file may still be opened from Teams. The difference is that SharePoint should be treated as the managed home, not as an invisible technical layer people only visit when something goes wrong.
When Teams should be the default
Use a Team when a defined group needs to work together regularly and the files are part of that work. This is particularly effective for projects, departments, service teams and time-bound initiatives where conversations and documents naturally belong together.
A project Team, for example, might contain the current plan, working budgets, meeting notes, risk log and supplier documents. Team members can co-author files, refer to them in channel conversations and find them beside meeting recordings and task updates. There is no need to create a separate SharePoint destination just because the files are important.
Teams also works well where speed matters more than formal publishing. A working draft does not need a polished intranet page, a document owner and a carefully designed set of metadata fields on day one. Too much structure too early encourages people to save files elsewhere.
That said, a Team should not become a catch-all archive. Teams are easy to create, and that convenience can leave organisations with dozens of abandoned workspaces, unclear owners and several versions of the same document. A Team needs a purpose, named owners and a decision about what happens to its content when the work ends.
Channel type affects where files live
Standard channel files are held in the parent Team’s SharePoint site. Private and shared channels are different: each has its own connected SharePoint site for files. This is useful when access needs to be restricted, but it can make document structure harder to understand if private channels are created casually.
Use private channels for a genuine confidentiality requirement, such as a limited commercial workstream. Do not use them simply because a folder feels tidier. More separate sites mean more places to manage permissions, ownership and lifecycle.
When SharePoint should be the default
SharePoint should lead when the audience is wider than a single working group, when documents need stronger control, or when people must be able to find information without joining a Team.
Consider HR policies. Employees may discuss changes in an HR Team, but the approved policy should sit in a clearly owned SharePoint library or intranet area. Staff need one published version, not access to a working channel containing draft copies, comments and old attachments.
The same applies to organisation-wide templates, quality procedures, sales collateral, operating manuals and formal board-approved material. These documents need an obvious owner, a review date, controlled access and a reliable route for the wider business to find them. A SharePoint communication site or departmental site is generally a stronger fit than a busy Teams channel.
SharePoint is also the better place to build a consistent experience around content. A document library can be surfaced on an intranet page alongside news, contacts, guidance and useful links. This is where a well-configured SharePoint intranet earns its keep: people do not need to know the name of the Team or folder path before they can find what they need.
Do not duplicate files to solve a navigation problem
The most expensive habit in Microsoft 365 is not using the wrong folder. It is maintaining copies in several places because users cannot find the original.
A proposal copied from a project Team into a sales library, then attached to an email and saved on a laptop, quickly becomes four competing versions. Version history only helps when people are working on the same file. It cannot decide which duplicate is authoritative.
Keep one source file and make it easier to reach. In Teams, add a link or tab to a relevant SharePoint library rather than uploading another copy. On a SharePoint intranet, point users to the live project document or approved library. Where a document changes status from draft to approved, move or publish it through an agreed process, rather than leaving several versions spread across channels.
This approach requires a little discipline, but it removes a great deal of avoidable checking, rework and uncertainty.
A simple decision test for every document
Before deciding where a file belongs, ask four practical questions:
- Who needs it: a defined working group, a department or the whole organisation?
- Is it being actively developed, or is it an approved reference document?
- Does it need formal ownership, review dates, retention rules or restricted access?
- Will someone need to find it without knowing which Team created it?
If the answer points to a small group working together, start in Teams. If it points to wider discovery, controlled publishing or long-term reference, start in SharePoint. If both are true, store the authoritative file in SharePoint and expose it in Teams where the group needs it.
There will be exceptions. A highly confidential document may need a dedicated restricted site even if it is a published record. A small business with a simple structure may not need elaborate metadata for every library. The aim is not to make every file follow a perfect rule. It is to make the common cases obvious enough that people stop inventing their own systems.
Permissions: use membership, not folder-by-folder exceptions
Teams membership controls access to the files held in the Team’s connected SharePoint site. That is helpful because access follows the group people already understand. Add someone to the Team and they can join the work; remove them and access to its files goes too.
Problems begin when organisations break permission inheritance across individual folders to accommodate one-off requests. It may resolve an immediate issue, but it creates an access model few people can explain or safely maintain. Over time, former staff, external guests and old project members retain access longer than intended.
For most small and mid-sized organisations, it is better to create a separate Team, channel or SharePoint site when access genuinely differs. Keep ownership clear, review memberships periodically and avoid granting access directly to individuals unless there is no sensible group-based option.
Build a structure people can actually follow
Governance does not need to be a 40-page policy. A workable standard can be stated plainly: Teams are for active collaboration, SharePoint is for controlled and published content, and OneDrive is for an individual’s own work before it is ready to share.
Set a small number of naming rules, require at least two owners for important Teams and sites, and agree where common content types belong. For example, projects may have Teams, approved company policies may sit in a central SharePoint library, and intranet news assets may be managed by internal communications.
Then make the right places easy to use. Clear navigation, sensible library names and a useful intranet homepage do more for compliance than a lengthy reminder email. If staff can find the current policy in two clicks, they are far less likely to keep an outdated copy in a personal folder.
The real choice is between working space and source of truth
Teams helps people get work done together. SharePoint helps organisations keep content governed, findable and reusable. Because the two are connected, a sensible setup should let staff work in Teams without losing the control and visibility that SharePoint provides.
Start by choosing one document type that causes regular confusion – perhaps policies, project files or sales templates. Agree its authoritative home, remove duplicate copies and show staff the simplest route to it. A few clear decisions like that will improve document control far more than another wholesale migration or a new folder structure nobody understands.