Why two tracks
A single-track IA — every site governed the same way — fails at both ends of the spectrum. Treat all content as records-grade and you make day-to-day collaboration cumbersome. Treat all content as collaborative and you have no defensible records management for content with regulatory, legal, or long-term value.
The two-track model gives both ends what they need. Business-led sites operate with a light governance touch — owned by the business, organized to fit how teams work, with enough structure to be useful but not so much that they slow down. Functional and records hubs hold enterprise-critical content under tighter governance — defined retention, controlled permissions, structured metadata, and explicit lifecycle rules.
If the content matters to one business area, put it on a business-led site. If it matters to the enterprise — for compliance, regulatory, legal, or long-term institutional reasons — put it on a records or functional hub. Most organizations need both.
Business-led sites
Business-led sites mirror how the organization actually works. Each site is owned by a business area, structured to fit that area's content needs, and governed at a lighter touch. These are the sites where day-to-day work happens.
-
Owned by the business. A Site Owner from the business area. Brokers approve new sites in their portfolio.
-
Structured to mirror the org. Branch hubs, directorate hubs, division sites — whatever shape reflects the actual operating structure.
-
Light retention defaults. Generic retention policy (e.g., dispose 5–7 years after last modified) keeps storage manageable without forcing premature loss.
-
Standardized templates. Sites are provisioned from a defined catalog (operational, project, communication) so navigation and library structure are predictable.
-
No forced classification. Business areas tag content with metadata that fits their work; enterprise-wide classification is light.
Functional and records hubs
Functional and records hubs hold content that the enterprise — not just one business area — needs to manage. HR records, legal records, finance records, contracts, board materials, policy documents, audit evidence. These hubs are smaller in number, larger in governance weight.
-
Owned by the function. HR owns the HR Records hub, Legal owns the Legal Records hub, and so on. The function has a designated Information Manager.
-
Tight retention. Retention labels applied at the library or content-type level, with explicit disposition rules tied to record categories.
-
Controlled permissions. Access typically Visitor-by-default-restricted with Members granted explicitly. Sensitive content uses unique permissions on libraries or folders.
-
Structured metadata. Enterprise content types, managed metadata, and (where appropriate) document sets. Content is tagged consistently to support search and disposition.
-
Lifecycle rules. Content moves through defined states — active, archived, disposed — with explicit triggers.
HR Records (employee files, performance management), Legal Records (contracts, litigation, policies), Finance Records (audit evidence, vendor contracts, fiscal records), Board & Governance Records (board materials, committee minutes), Compliance Records (regulatory filings, certifications), Health & Safety Records (incident reports, training records).
Movement between tracks
Some content starts on a business-led site and becomes enterprise-critical later. A draft policy lives on the Policy team's site while it's being authored, then moves to the Policy Records hub when it's approved. A contract is negotiated on a project site, then moves to Legal Records when it's signed.
Three patterns for moving content:
-
Manual move. Site Owner or Broker explicitly transfers content when it crosses a threshold (e.g., policy approved, contract signed). Most reliable for low-volume cases.
-
Location-based. Content placed in a designated library is automatically routed (e.g., a 'Final Contracts' library on a project site syncs to Legal Records). Works well when business behavior is predictable.
-
Metadata-driven. Content tagged with a specific status (e.g., 'Approved' or 'Final') is automatically copied or moved. Requires consistent tagging.
-
Event-driven. Lifecycle events trigger movement (e.g., project closure moves all 'final' artifacts to the appropriate records hubs). Requires defined event triggers.
-
AI/auto-classification (future). Trainable classifiers identify enterprise-critical content and route it. Realistic only at scale and with E5 / SharePoint Premium.
Kybera Impact supports all four movement patterns. The Workflow Engine handles event-driven and metadata-driven moves; the Repositories module ships library templates that can be configured to auto-route to records hubs; the Compliance module manages the retention scopes and labels that apply once content arrives in the records track.
Most organizations should start with manual and location-based movement (low risk, predictable) and introduce metadata-driven and event-driven movement as Phase 2 once the patterns are stable.
Hub hierarchy
SharePoint supports up to three levels of hub hierarchy. A working pattern is to put the enterprise hubs at level 1, departments at level 2, and major functions at level 3.
| Hub level | Examples (business-led) | Examples (records/functional) |
|---|---|---|
| Level 1 — Enterprise | Tenant root / SharePoint home | Records & Compliance Hub |
| Level 2 — Department / Function | HR Hub, IT Hub, Operations Hub | HR Records, Legal Records, Finance Records |
| Level 3 — Major function within department | HR ⇒ Talent Acquisition, Learning, Compensation | Legal Records ⇒ Contracts, Policies, Litigation |
Not every department needs three levels. Most should start with Level 1 + Level 2 and add Level 3 only where the content volume or governance complexity justifies it.
Hub navigation standard
Consistency across hubs is what makes a multi-hub IA feel like one platform. Define a small set of first-level navigation headers that appear on every hub:
-
Our Spaces. Links to the operational sites within this hub family. Required.
-
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 hub.
-
Projects & Initiatives. Active projects and initiatives the hub is running.
Functional/records hubs may use a slightly different first-level header set — for example, 'Records', 'Policies', 'Templates', 'Reference' — but the principle is the same: the user should encounter a familiar shape on every hub they visit.
Don't try to populate every header on every hub from day one. The structure is the consistency; the content matures over time. Create the headers, leave them empty, populate as the hub matures.
URL structure
URLs are part of IA. Department names change; URLs that hard-code department names break every link in the organization when the change happens.
-
Use a stable URL convention — numeric IDs (e.g., /sites/12345), short codes, or another scheme that doesn't change when the org chart does.
-
Avoid putting business names in URLs.
-
Keep URLs short — long URLs break in email clients and become hard to share verbally.
Impact-provisioned sites use a standardized URL convention defined in the workspace template. Site renames don't break URLs because the URL doesn't reflect the business name. The Workflow Engine handles association, hub registration, and naming standards consistently across the tenant.
Discussion Questions
• What content in this organization is genuinely enterprise-critical — and therefore belongs on functional/records hubs?
• Which functional hubs do we need on day one (HR, Legal, Finance, Board)?
• How does content move from business-led sites into records hubs today, and how should it move in the target state?
• Are we comfortable starting with manual movement and adding metadata/event-driven later, or do we need automation from day one?
• What hub structure mirrors how the organization actually works — by department, by region, by function?
• How many levels of hub hierarchy do we need? Where would three levels add value vs. just complexity?
• What URL convention works for us — numeric IDs, codes, short names?
• What hub navigation standard fits our organization's vocabulary?