Most SharePoint Online environments aren’t designed. They accrete. A team needs a place to share files, so someone in IT spins up a site. Another team has a project, so they get another site. A vendor sends a Teams invite, so a third site appears as a Microsoft 365 Group is silently created in the background.
Two years later, the organization has 80 SharePoint sites, no consistent naming convention, mystery permissions, and content scattered in ways that make finding anything a small daily challenge.
The four decisions below are the ones that, if made deliberately and early, prevent most of this. Made by accident — or not made at all — they’re the source of the sprawl.
Decision 1: How sites get created
The first decision is who can create new SharePoint sites and Microsoft 365 Groups.
Out of the box, Microsoft 365 lets any licensed user create a Group, which automatically provisions a SharePoint site, a Teams channel, an inbox, a calendar, and a OneNote notebook. This is great for adoption — it means people aren’t blocked waiting for IT — and it’s terrible for governance, because every new Team in Microsoft Teams creates a new SharePoint site that nobody named, classified, or assigned an owner.
The remediation isn’t to lock everything down. That kills adoption and creates an IT bottleneck that nobody wants. The remediation is a provisioning workflow: a lightweight intake process where a requester answers a few questions (purpose, owner, expected lifetime, sensitivity), and the site or Team gets created with a consistent naming convention, appropriate permissions, and a documented owner.
This can be as sophisticated as a Power Apps form feeding a Power Automate provisioning flow, or as simple as a SharePoint list with email notifications. What matters is that the questions get asked, and answers get recorded.
The decision is whether to leave creation open (sprawl) or gate it behind intake (governance). Most growing businesses should choose intake by the time they have a third SharePoint site.
Decision 2: How content gets organized
The second decision is the information architecture — the structural framework for how content gets organized across sites.
The two extremes are both bad. One giant site means everything is searchable from one place but permissions become impossible to manage. One site per topic, project, or team means clean permissions but content scattered across hundreds of sites with no relationships between them.
The middle path is a hub-and-spoke architecture. A small number of hub sites correspond to major organizational divisions (departments, practice groups, regions). Spokes are the working sites — projects, teams, initiatives — that associate with their relevant hub. The hub provides cross-site navigation, search, and shared branding; the spoke handles the actual work and its specific permissions.
This structure scales. New work gets a new spoke under the right hub. Old work gets archived without disrupting the rest. The hub gives users a place to start when they’re not sure where something lives.
The decision is whether to design the architecture early (when you have 10 sites) or retrofit it later (when you have 100). The retrofit is dramatically more painful.
Decision 3: How permissions get assigned
The third decision is permissioning, and the failure mode is universal: organizations grant access by adding individual users to sites, ad hoc, in response to “I need access to X” requests, until nobody can answer who has access to what or why.
The fix is permission groups, not user permissions. Access gets granted to groups (security groups in Entra ID, or Microsoft 365 Groups) that correspond to organizational realities — practice groups, project teams, leadership tiers. Sites get configured to grant the appropriate group access. New people join the relevant groups; their site access follows automatically. People who change roles get moved between groups; their access updates without site-by-site manual cleanup.
The harder part is sensitivity-based labeling, which adds another dimension. A “Highly Confidential” label might restrict a document to a specific group regardless of where the document is stored. A “Public” label might allow broader access. The labels travel with the document, which means access is determined by content sensitivity rather than location.
For most growing businesses, the practical advice is: start with group-based site permissions immediately, layer sensitivity labels on top within the first year, and never grant access to individual users except in genuine exceptions.
The decision is whether to do permissions deliberately (which costs an afternoon of setup and ten minutes per new site) or reactively (which costs days of forensic investigation any time something goes wrong).
Decision 4: What to do with old content
The fourth decision is content lifecycle: what happens to sites and content when the work they support concludes.
The default is nothing. Project ends, project site stays. Two years later it’s still searchable, still surfacing in user queries, still containing information that was relevant in 2024 but is misleading now. Multiply that by every project the organization has ever run, and search results become a chronological mush.
The fix is a retention policy combined with a lifecycle workflow. Retention policies handle the technical side: documents get archived or deleted based on age, label, or location. The lifecycle workflow handles the human side: site owners get periodic prompts to review their site (“Is this site still active? Should we archive it?”), and ownership doesn’t go undefined when an owner leaves the company.
The decision is whether to plan for content retirement (which means reviewing sites every six months) or to let everything accumulate forever (which means search degrades steadily until users stop using it).
This is the hardest of the four decisions because it requires ongoing organizational discipline rather than a one-time setup. But it’s also the one with the most compounding effect: an organization that retires content cleanly will have a usable SharePoint environment in five years; an organization that doesn’t will have a graveyard.
Why the order matters
These four decisions reinforce each other. Provisioning workflow makes governance possible. Information architecture makes organization possible. Permission groups make access auditable. Lifecycle policy makes the whole system maintainable.
Skip any one and the others get harder. Skip provisioning and you can’t enforce architecture. Skip architecture and you can’t structure permissions. Skip permission groups and you can’t audit anything. Skip lifecycle and the other three drown in clutter within a few years.
Most growing businesses make none of these decisions explicitly. The decisions get made by default — in the direction of “let people do whatever they need to do” — and the consequences arrive as a slow accumulation of friction that nobody quite notices until search has stopped working and finding any document is a quest.
The decisions are easier to make deliberately on the front end than they are to retrofit later. They don’t require a massive consulting engagement; they require a single afternoon of conversation, a documented framework, and the discipline to follow it as the environment grows.
That’s the work. It’s the difference between SharePoint as a useful platform and SharePoint as the place documents go to be lost.