Your team moved project files into Microsoft Teams. Collaboration got better. Then someone asked for last year's proposal, and nobody could find it.
The usual first fix is a hub site. It rarely works, and the reason is worth understanding before you spend a weekend on it.
Search is trimmed before scope is applied
Microsoft Search is security-trimmed. Results are filtered by what the user is allowed to open, and that filtering happens before any hub scope is applied.
A hub site associates sites, unifies navigation, and gives you a scoped search across the family. What it does not do is grant anyone permission to anything.
So if Alice is not a member of the Northwind Team, associating that team's site with a hub does not put Northwind's files in Alice's results. She gets the same empty page, now with nicer navigation.
The other fix is worse
The workaround people reach for next is adding everyone to every Team. This does restore search — and it costs you the two things the move to Teams was supposed to buy.
Channel noise goes up for everyone, permanently. And confidentiality boundaries that used to be implicit in membership stop existing. If any of your projects involve client data, salary data, or anything under an NDA, this trade is usually unacceptable once you say it out loud.
The collision is at the permission layer
"Open by default" and "team-scoped membership" are both reasonable goals. They are not compatible in the same container.
Once you see it that way, the question stops being "which search setting did I miss" and becomes "which content should be readable by the whole organization, and where does that content live." That is an information architecture decision, not a toggle.
A shape that usually works
Three tiers, and the middle one is the part most setups are missing.
Active work stays where it is — inside each Team's own site, with current membership unchanged. Nothing about day-to-day collaboration changes.
A read tier for completed work. Closed projects move to their own site (or a small set of sites) with an organization-wide read group, surfaced through a hub and, if you want it clean, a scoped search vertical. Now discovery costs no Team membership.
Exceptions go through SharePoint's built-in request-access flow rather than a Team invitation. Someone finds a file they cannot open, asks, and gets read access to that item — without joining a channel they will never use.
The interesting design work is almost entirely in tier 2: what moves, when it moves, and what is deliberately excluded from it.
What to check before you change anything
- List your Teams and the SharePoint site behind each one. Private channels have their own separate sites; they are easy to forget and they behave differently.
- For each site, write down who actually has read access today. Not who you think should — who does.
- Decide, explicitly, which projects must never enter the read tier. Write the rule down before you build anything, because this is the decision that is expensive to reverse.
- Confirm whether your Teams are private or public-but-unlisted. Public teams are already discoverable and may need less work than you think.
The honest caveats
Exact behavior varies with your tenant: how sites were provisioned, whether sensitivity labels are in play, and whether anyone has customized search configuration. Treat the above as the shape of the answer, not a script. Anything you cannot verify in your own tenant should stay marked as an assumption until you check it.
If it helps, map your current state first and decide second. Most of the pain I see described in this area comes from changing permissions before anyone wrote down what the permissions currently are.
