What a SharePoint site is
A SharePoint site is a container for shared work. It brings together content, people, and tools in service of a specific business purpose — a department, a project, a function, an intranet area. A site is not just a place to store files. It is a workspace.
A site can hold:
-
Pages. Information, news, intranet content for defined audiences.
-
Document libraries. Structured storage for shared files with versioning, metadata, and permissions.
-
Lists. Tables for tracking work, requests, inventories, processes, decisions.
-
Forms. User input that saves data into lists or libraries.
-
Apps and integrations. Power Apps, Power Automate, third-party solutions, custom web parts.
-
Governance, retention, and security controls. Policies that apply to everything in the site.
Each site has its own:
-
Navigation.
-
Permissions.
-
Settings (language, features, metadata, sharing).
If you think of SharePoint as a file share, you're missing most of its value. The site is the workspace; libraries and lists are tools inside that workspace; permissions, retention, and navigation give it shape.
Site types
Microsoft 365 ships three primary site types. Each has a different intended use and different governance posture. Most organizations will use all three, but the boundaries matter.
| Site type | Purpose | Governance posture |
|---|---|---|
| Communication site | One-to-many information broadcasting. News, intranet pages, policies, organizational landing pages. | Centrally curated. Small number of authors, large audience. Policies often determined by the organization. |
| Team site (Group-connected) | Active collaboration on documents, conversations, tasks. Project workspaces, committees, communities. | Norms typically determined by the team. Group membership controls access. Often connected to a Microsoft Team. |
| Team site (no Group) | Structured collaboration where a Team isn't appropriate. Departments, operational areas, long-running functions, sensitive content. | More controlled permissions (Owners/Members/Visitors). No mailbox, no Teams pressure. Better for content-heavy long-term work. |
Kybera Impact exposes these as distinct workspace templates in the request flow. Selecting a template drives the right shape (Communication vs. Team-with-Group vs. Team-no-Group), the right defaults (sharing, permissions, hub association, retention scope), and the right lifecycle policy. Without templates, every site type ends up looking like every other site type.
What hub sites are
A hub site is a way to group related SharePoint sites together so that they share navigation, search, theme, and content roll-ups. Hubs are the connective tissue of a modern intranet. Without them, sites become isolated islands — content exists, but it's hard to find and navigate.
What a hub provides:
-
Consistent navigation. Hub navigation is published from the hub site to every associated site, so users see the same structure regardless of where they land.
-
Hub-scoped search. Search performed from any associated site can be scoped to the hub family.
-
Aggregated news and content. News and selected content from associated sites can roll up to the hub.
-
Shared theme. Hubs apply a consistent visual identity across associated sites.
-
A predictable entry point. Users have one place to start instead of needing to bookmark every site.
How hubs work
-
Any SharePoint site can be registered as a hub site (most commonly a Communication site).
-
Other sites are associated with the hub. Association is a link, not a hierarchy — sites can move between hubs without breaking content URLs.
-
Up to three levels of hub hierarchy are supported (e.g., Enterprise → Department → Function).
-
Microsoft recommends keeping hub families practical: roughly 100 sites for navigation, around 2,000 for shared search.
-
Association does not change permissions on a site. A restricted site associated with a hub stays restricted; users without access don't see its rolled-up content.
As a general rule, every SharePoint site should be associated with a hub. Hubs provide structure without locking the organization into rigid hierarchy — connections are easy to change as the business evolves.
A working hub structure
A typical hub structure mirrors how the organization actually works. The exact shape varies, but a common pattern is:
-
Tenant root / home site. A Communication site that serves as the front door to SharePoint. Hosts the SharePoint App Bar global navigation. Not a full intranet — that may be a separate initiative.
-
Department hubs. One per department or major function (HR, Finance, IT, Operations). Each hub serves as the entry point for that department's users.
-
Operational sites under each hub. Department-level sites for specific functions, teams, or capabilities. These are where day-to-day collaboration and content storage happens.
-
Records / functional hubs. Tightly governed hubs for HR records, legal records, finance records, and similar enterprise-critical content. Different governance posture from business-led sites — see Doc 2.3.
Hub registration, hub association, and hub navigation can be managed manually through the SharePoint Admin Center, but at scale this becomes a maintenance burden. Impact's Workspaces module sets hub association during provisioning (mandatory for operational sites), pushes consistent navigation, and surfaces hub orphans (sites not associated with any hub) through Insights.
Navigation standards
Navigation is what makes a hub feel like one place rather than ten. A consistent navigation structure across all hubs reduces the learning curve and signals that the platform is governed.
A working pattern is to define a small set of first-level headers that appear on every hub:
-
Our Spaces. Links to operational sites within the department or function.
-
Services & Functions. Services this department offers to the rest of the organization.
-
Committees & Governance. Committees, governance bodies, and councils led or participated in by this department.
-
Projects & Initiatives. Active projects and initiatives the department is running.
Not every header needs to be filled in on every hub from day one — the structure is the consistency, the content matures over time. Hub navigation, like the hub itself, is actively maintained as the organization changes.
Navigation maintenance is a real cost. If new sites are not added to hub navigation when they're provisioned, the navigation drifts out of date within a quarter. Make navigation updates part of the site provisioning process — not an afterthought.
Navigation updates are part of the workspace request flow. When a new site is provisioned and associated with a hub, Kybera Impact can prompt the requester (or the hub owner) to register the site in hub navigation. Insights surfaces hubs whose navigation is out of date.
Discussion Questions
• Which site types are sanctioned in our organization, and what's the default for each kind of work?
• Are we comfortable with every site being associated with a hub by default?
• What hub structure reflects how the organization actually works — by department, by function, by region?
• Do we want a global navigation experience (App Bar from a tenant home site)?
• What first-level headers should appear consistently on every hub?
• Who owns hub navigation maintenance? How does it get updated when a new site is added?
• Do we want centrally-curated intranet hubs, federated hubs with common standards, or both?