A Document Set groups multiple related files — with shared metadata, a shared welcome page, and versioning that treats them as one unit — instead of a loose folder where nothing ties the files together conceptually.
In this post: Prerequisites · What you actually get over a plain folder · Creating a Document Set · Permissions and shared columns settings · When would you actually use this?
Prerequisites
You need to be a Site Collection Administrator to activate Document Sets — a regular Site Owner can’t turn this on themselves, so factor that into who needs to be involved. It’s also a site-collection-level feature: you activate it once at the top-level site, and it becomes available across the whole site collection from there, not per-subsite.
Worth knowing before you set this up: it’s more structure than a handful of files needs. The value shows up when you’re managing many similar bundles repeatedly (every project, every new hire) — for a one-off group of files, a plain folder with good metadata is less overhead.
What you actually get over a plain folder
Two specific things a folder doesn’t give you:
A real welcome page, not just a file listing. Opening a Document Set shows a page built from two Document-Set-specific web parts: one displaying the set’s shared metadata (client name, status, whatever columns you defined), the other listing the actual files inside it. Anyone opening it gets the context and the contents in one view, instead of a bare folder with no idea what they’re looking at.
Capture Version, for the whole set at once. Individual files still get their own automatic version history. But Document Sets add a separate, manual action — Capture Version — that snapshots the properties and every document in the set together, with a comment, at a point in time. Restore that snapshot later and you get the whole set back as it was, not just one file. A folder has no equivalent: reverting “the project as it stood at proposal stage” isn’t something you can do to a folder in one action.
Creating a Document Set
Worked example: a “Client Onboarding” Document Set with three shared columns — Client Name, Account Manager, Start Date.
- Activate the feature (once, site-collection-wide): Site Settings > Site Collection Administration > Site collection features > activate Document Sets.
- Create the content type: Site Settings > Site Content Types > Create, with Document Set as the parent content type. Add the three columns above — these are what every file dropped into a “Client Onboarding” set will inherit automatically.
- Add it to a library: Library Settings > Add from existing site content types, select “Client Onboarding,” and optionally set default templates (a blank contract, a welcome letter) that get created automatically inside every new set.
- Create one: New > Client Onboarding, fill in the three shared columns once. Now drop in the contract, the intake form, and the welcome packet — all three inherit Client Name, Account Manager, and Start Date without anyone re-entering them per file.
A Document Set applies shared metadata and versioning across every file inside it — the files stay individually editable, but they’re managed as one unit.
Permissions and shared columns settings
Two settings on the Document Set content type are worth knowing before you build one for real use. First, under Document Set Settings > Shared Columns, you choose exactly which metadata fields propagate down to every file inside the set — it’s not automatically “all of them,” so a column you add later needs to be explicitly marked as shared if you want existing and new files to inherit it. Second, permissions can be managed at the set level: set unique permissions on the Document Set itself, and everything inside it inherits from that one point, rather than needing individual permission changes on the contract, the intake form, and the welcome packet separately. That’s the practical payoff of “managed as one unit” — change access once at the set level when, say, a client relationship ends, instead of hunting down every file that belonged to it.
When would you actually use this?
- A project has multiple related documents (scope, requirements, deliverables) that should share metadata and move through approval together, not as separate untracked files.
- A legal matter has contracts and supporting documents that need to stay grouped with consistent metadata for retrieval during review or audit.
- Each new hire needs the same bundle of onboarding documents (forms, policies, training material) — a Document Set template makes this repeatable instead of manually collecting files per person.
That covers it for now. Questions welcome in the comments.
App Catalog Authentication Automation Backup Compliance Content Type CSS Flows Google Javascript Limitations List Metadata MFA Microsoft Node NodeJs O365 OneDrive Permissions PnP PnPJS Policy PowerApps Power Automate PowerAutomate PowerPlatform PowerShell React ReactJs Rest API Rest Endpoint Security Send an HTTP Request to SharePoint SharePoint SharePoint List SharePoint Modern SharePoint Online SPFX SPO Sync Tags Teams Termstore Versioning