SharePoint document management for Dynamics 365
How Dynamics 365 stores documents — the SharePoint integration model, folder structure, permissions, and operational gotchas.
Documents in Dynamics 365 don't live in Dataverse — they live in SharePoint Online. The integration is configured per record type, automatic per record, and almost always the right choice. Understanding how it actually works prevents the surprises that catch new admins out.
The model. When an admin enables SharePoint integration for a Dataverse table (say, Account), every record of that table automatically associates with a folder in a configured SharePoint site. Users see a Documents tab on the record that shows the contents of the folder; uploads, downloads, and edits happen through the SharePoint experience, but inline with the CRM record.
The folder structure. By default the structure is:
<root site>/<entity name>/<record name> (<record GUID>)/
So Account "Contoso Ltd" gets a folder named "Contoso Ltd (a1b2…)" inside the Accounts library. The GUID suffix is what disambiguates two records with the same name and what keeps the link stable if the name changes.
Hierarchical folders. A common configuration nests folders to follow a hierarchy — e.g. Contacts under their Account, Opportunities under their Account. This requires folder-based document management to be enabled per table.
Permissions. Documents inherit SharePoint permissions, not Dataverse permissions. By default the SharePoint site is shared with all Dynamics 365 users, so anyone with CRM access sees the documents. For finer-grained control, customers configure SharePoint at the library or folder level. This is the most common cause of "I can see the record but not the documents" support tickets.
Search. Dataverse search indexes document metadata and titles but not always the document content; SharePoint search indexes content. Cross-system search is improving but isn't seamless yet.
Co-authoring and check-in/check-out. All standard SharePoint features apply: simultaneous editing in Office on the web, versioning, check-in/check-out for sensitive documents.
Limits.
- 5 GB per file (SharePoint limit, occasionally tighter on tenants).
- 30 million items per SharePoint library before list-view performance degrades.
- Renaming the underlying record doesn't rename the folder (it keeps the original name to maintain link stability).
Migration. Moving existing documents into a freshly-configured SharePoint integration is a structured task — migrate documents while preserving folder structure, then run the metadata mapping job to associate them with Dataverse records. Third-party tools (ShareGate, Metalogix, Power Automate flows) speed this up considerably.
Why SharePoint, not Dataverse. Dataverse storage is expensive; SharePoint storage is cheap, included generously with Microsoft 365 licences, and built for document collaboration. The integration gives you both: relational data in Dataverse, documents in SharePoint, unified at the record level.
Related guides
- Async jobs in DataverseHow Dataverse runs background work — system jobs, async plug-ins, workflow runs, and how to monitor, troubleshoot, and prevent the async backlog from getting out of hand.
- Document templates and Word mail merge in Dynamics 365How to generate Word and Excel documents from Dataverse records — document templates, mail merge, and the customer-facing document workflow.
- Account hierarchies in Dynamics 365How Dynamics 365 models corporate parent-subsidiary relationships — account hierarchy field, hierarchy charts, security, and reporting roll-up.
- App designer for model-driven appsHow to build a model-driven Power App — site map, tables, forms, views, business process flows, dashboards, and the app-experience layer.
- Bulk delete jobs in DataverseHow Dataverse's bulk delete handles mass record cleanup — scheduling, filters, retention policies, and the operational discipline around storage management.