The building blocks
- Site columns — reusable field definitions (a "Department" choice, a "Contract date") defined once at site (or hub) level and reused across many lists, so the field means the same thing everywhere.
- Content types — named, reusable bundles of columns + behaviour (a template, a document template, a retention/label default). "Contract", "Invoice", "Policy" as content types carry their own metadata and rules wherever they're used.
- The Content Type Gallery / hub — publish content types tenant-wide so every site inherits the same "Contract" definition; changes propagate down.
- Managed metadata + the term store — a central, hierarchical taxonomy (term sets) surfaced as managed-metadata columns, giving controlled, consistent tagging instead of free-text drift.
Folders vs metadata (the scale argument)
Folders impose a single rigid hierarchy — a file lives in one place, and finding it means knowing the path someone chose years ago. Metadata lets the same file be filtered, grouped and viewed many ways at once (by client, by year, by status) without moving it. At scale, metadata wins decisively, and there's a hard technical reason as well as an ergonomic one.
The 5000-item list view threshold (the wall)
SharePoint lists/libraries enforce a list view threshold of 5,000 items per view/query. Beyond it, a view that isn't backed by an indexed column is throttled and errors out ("this view cannot be displayed"). The fixes:
- Index the columns you filter/sort on (a column index lets a query return a sub-5000 slice efficiently).
- Filter views so any single view returns under the threshold.
- Metadata + indexed columns scale to millions of items; folders were the old workaround (each folder is a smaller scope), which is why folder-heavy libraries feel fine until a flat view is attempted.
The failure modes
- Free-text instead of managed metadata → "Finance", "finance", "Fin Dept" all coexist and no filter is reliable. Term store discipline prevents this.
- Hitting 5000 with no indexed column → views break; users blame "SharePoint is slow" when it's an IA problem.
- Folder path length (sync-client concept) — deep folder trees also break the ~400-char path limit; metadata has no such cost.
- Content type changes not propagating — publishing from the gallery is asynchronous; a "Contract" change can take time to reach every site, and a site that opted out won't get it at all.
What to watch (proofs)
- Indexed columns: Library settings → Indexed columns — confirm the columns your big-library views filter on are indexed (the 5000-wall fix).
- Item counts approaching the wall:
Get-PnPListItemcounts / library item count in settings — libraries nearing 5,000 unindexed items are latent breakage. - Term store health: the Managed Metadata term store admin — is there a governed taxonomy, or is tagging free-text?
- Content type propagation: the Content Type Gallery publish status — has the latest definition actually reached the sites that consume it?