SharePoint document management

What it does

Stores documents for Dynamics 365 records in SharePoint rather than in Dataverse, and surfaces them on a Documents tab on the record. Dataverse keeps a pointer — a document location record — and SharePoint keeps the file.

Key facts

Enabled per environment in the Power Platform admin centre at Settings > Integration > Document management settings, starting with Enable server-based SharePoint integration and a wizard that asks for the SharePoint site URL.
Once server-based integration is on, you cannot revert to the older client-based authentication model. Treat it as a one-way door.
SharePoint and Dataverse must be in the same Microsoft 365 tenant. Cross-tenant is not supported.
A Global Administrator has to enable it. Delegated admins cannot.
Supports SharePoint in Microsoft 365, and on-premises SharePoint 2016 or 2013 SP1 and later. SharePoint Foundation editions are not supported.
Document management is then switched on table by table, choosing which entities get a Documents experience and which SharePoint site holds them.
A hierarchical folder structure — documents nested under an account or contact — is only created automatically for Opportunity and Contract. Other tables with multiple N:1 relationships to the parent do not get it.
The relationship to the SharePoint Document entity must be 1:N for documents to appear. N:1 or N:N relationships mean the Documents tab renders nothing.
Permissions are SharePoint's, not Dataverse's. A user's Dynamics security role does not restrict what they can open once they have site access.
If SharePoint access control is set to block unmanaged devices, Dynamics gets 401 Unauthorized when it calls SharePoint. The documented workaround is to allow full access from unmanaged devices, which most security teams will not accept without discussion.
Library names in SharePoint need to match the entity display names. Mismatches surface as validation errors later, typically during an upgrade.

When to use / skip

Use it on almost every Sales implementation. Storing proposals and contracts as Dataverse notes is expensive, unsearchable and unversioned; SharePoint gives you co-authoring, versioning, retention labels and a place the rest of the business already looks.

The place to be careful is the client who wants Dynamics to be the access-control layer for documents. It is not, and no amount of configuration makes it one. If confidentiality on deal documents is a genuine requirement — restructuring, M&A, anything with a deal team — the answer is separate SharePoint sites with their own permissions, and you should say so before the design is signed off.

Skip the fancy structures. A folder per record on one site, with the out-of-the-box structure, survives contact with reality. Elaborate site-per-account designs look tidy in a diagram and become unmanageable at a few thousand accounts.

Configuration decisions

Which site collection holds the libraries, and whether it is an existing team site or a new one created for the purpose. This is effectively permanent.
Which tables get document management. Account, Contact, Opportunity and Quote are the usual set; adding tables later is easy, removing them is not.
Whether to take the Opportunity-under-Account folder hierarchy or keep everything flat. Hierarchy is only automatic for Opportunity and Contract, so a consistent structure across other tables means building it yourself.
How SharePoint permissions map to the sales organisation, given Dataverse roles do not apply.
Whether OneDrive for Business is enabled alongside, which changes where a seller's draft documents land.
Retention and labelling policy on the target site, agreed with whoever owns information governance.

Gotchas

Server-based integration cannot be undone. If you point it at the wrong site during a proof of concept, plan on a new environment rather than a reversal.
The permissions gap is the recurring surprise: a seller with no access to an opportunity in Dynamics can often open its documents directly in SharePoint.
Deleting a record in Dynamics does not delete the SharePoint folder. Over a few years this becomes a meaningful volume of orphaned content, and a subject-access headache.
Conditional access policies that block unmanaged devices break the Documents tab with a bare 401 and no explanation on the Dynamics side.
Multi-geo tenants and environments in a different region from the SharePoint site produce latency and, occasionally, compliance objections. Check the geography of both before designing.
Document locations are records. Bulk-moving or renaming SharePoint folders outside Dynamics leaves them pointing at nothing.
Renaming an entity display name after the fact desynchronises it from the library name and surfaces during upgrades, not immediately.

Consultant notes

Get the SharePoint owner into the design session. This integration fails on governance far more often than on configuration.
Demo it against Opportunity with the folder hierarchy visible — it is the one place the out-of-the-box structure looks deliberate.
State the permissions position in writing during design, not in a defect triage after UAT.
Before go-live, test the Documents tab from a locked-down device under the client's real conditional access policy, not from your own laptop.
If the client asks for document approval workflow, keep it in SharePoint or Power Automate. Building it in Dynamics duplicates a capability they already own.

Worth another look if the client's information governance policy or conditional access posture changes.