Document ID assigns every document in a site collection a permanent identifier and a stable redirect link that survives moves and renames — genuinely useful, but with one real limitation worth understanding before relying on it: that persistence only holds within a single site collection, not across them. This post covers how it actually works, the real limitation, how to enable it, and the search-syntax gap that trips people up once modern pages are involved.
In this post: How it actually works · Searching by Document ID on a modern page · The real limitation: site collection boundaries · Enabling it with PowerShell · When would you actually use this? · Related reading
How it actually works
Once enabled, every document in the site collection gets a unique ID — a configurable 4-to-12-character prefix (letters and digits only) followed by a sequential number, like `FINC-1234567890`. That ID resolves through a fixed redirect URL regardless of where the document currently lives inside the site collection:
https://yourtenant.sharepoint.com/_layouts/15/DocIdRedir.aspx?ID=FINC-1234567890Move the document to a different library, rename it, even reorganize the folder structure around it — that link keeps resolving to the same document, as long as the move stays inside the same site collection. Document IDs are also mapped to a managed search property (`DlcDocId`), so a document can be located by its ID through search directly, not just the redirect link. Worth distinguishing move from copy here too: a genuine move preserves the ID, but a copy — including the common case of downloading a file and re-uploading it elsewhere — creates a new ID for the copy, treating it as a distinct document rather than the same one relocated.
Searching by Document ID on a modern page
Worth knowing directly since it’s a real, easy-to-hit dead end: classic SharePoint had a dedicated “Find by Document ID” web part that let someone type a raw ID and get the matching document, no extra syntax required. That web part has no modern-page equivalent — searching by Document ID today means typing the managed property prefix explicitly:
DlcDocId:FINC-1234567890Typing the raw ID alone into a modern search box, without the `DlcDocId:` prefix, doesn’t reliably surface the document — a genuinely confusing experience for anyone expecting the classic-page behavior. Worth documenting this exact syntax somewhere visible to end users if Document ID search is actually meant to be a day-to-day workflow, rather than assuming it’s discoverable on its own.
Document ID survives a move within a site collection. Move a document to a different site collection, and the ID regenerates — every existing link to it breaks, with a “No documents with this ID were found” error.
The real limitation: site collection boundaries
Worth understanding precisely rather than as a vague “limited granularity” caveat: Document ID persistence is scoped strictly to the site collection it was assigned in. Move a document to a different site collection — even within the same tenant — and the ID doesn’t travel with it; a new one gets generated at the destination, and every existing link built around the old ID stops resolving, surfacing a “No documents with the ID <xxx> were found in this site collection” error to anyone who follows an old link or bookmark. If the destination site doesn’t have the Document ID feature enabled at all, the moved document loses its ID entirely, with no ID assigned there.
This matters more than it might first appear given how common cross-site-collection moves actually are — migrating content between departments, consolidating sites, or restructuring hub associations all typically involve moving documents across that exact boundary. Any workflow, bookmark, or external system built around a Document ID link needs to account for this before a reorganization happens, not after links start breaking.
Enabling it with PowerShell
Connect-PnPOnline -Url "https://yourtenant.sharepoint.com/sites/yoursite" -Interactive
# Enable the Document ID feature (site-collection scope)
Enable-PnPFeature -Scope Site -Identity "b50e3104-6812-424f-a011-cc90e6327318"
# Set a custom prefix (4-12 characters, letters and digits only)
Set-PnPSiteDocumentIdPrefix -DocumentIdPrefix "FINC" -ScheduleAssignment $true -OverwriteExistingIds $trueWorth planning around rather than expecting instantly: assigning IDs to every existing document in a large site collection isn’t immediate — the background job can take up to 48 hours to finish across all files, and newly-added documents get their ID immediately going forward while the backlog catches up. Also worth knowing directly: the ID prefix itself can’t be reset via PowerShell once set — changing it requires going through the site settings UI, not a repeatable script, so it’s worth getting the prefix right the first time rather than treating it as easy to adjust later.
When would you actually use this?
- A single site collection with documents that move between folders/libraries often, where stable links genuinely matter — Document ID solves exactly this.
- Regulated or compliance-heavy environments needing a standardized way to reference specific documents in audit trails, contracts, or records — as long as those documents don’t cross site-collection boundaries later.
- A tenant with a lot of cross-site-collection reorganization planned — worth solving link stability at a different layer (a managed metadata reference ID stored as a column, for instance) rather than relying on Document ID for anything expected to move between collections.
- A small site with low document turnover — the configuration overhead genuinely may not be worth it if links rarely break in the first place.
- End users are expected to search by ID regularly — worth pairing the feature with actual training on the `DlcDocId:` search syntax, since the modern experience doesn’t make that discoverable on its own.
Related reading
- How to Migrate SharePoint Online Content to Another Tenant — relevant since a migration is exactly the kind of move that breaks Document ID links.
The feature does exactly what it promises within a site collection — the real planning question is whether “within a site collection” actually matches how documents in your environment move over time, not whether the feature itself works as documented. Worth revisiting that assumption specifically whenever a site restructuring, migration, or hub reorganization is being planned, rather than only discovering the boundary the first time a link someone bookmarked stops working.
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