Dynamics 365 SharePoint Permissions: The Security Model Your IT Policy Is Missing

There is a conversation happening in IT security teams across every industry, and it usually starts the same way. A routine audit flags a SharePoint document library. Inside it: sensitive customer contracts, financial records, or case notes — all accessible to users who have never logged into Dynamics 365 a single day in their lives. Nobody set out to create this exposure. It happened quietly, by design, the moment someone clicked Enable Server-Based SharePoint Integration in the D365 admin centre.

This post is not a product advertisement for any single tool. It is an architect-level walkthrough of the security model that most Microsoft implementation guides skip entirely — and the compliance checklist your CISO needs before signing off on any Dynamics 365 document storage architecture.

The Silent Security Gap Nobody Talks About

When you enable the native Dynamics 365 and SharePoint integration, documents attached to CRM records are stored in SharePoint document libraries that mirror your D365 entity structure. A folder is created per record — account, opportunity, case — and files live there. On the surface, this is elegant. In practice, it creates a permission boundary mismatch that most IT audits completely miss.

Here is the problem in plain terms: Dynamics 365 enforces row-level security through its own security role model. A sales representative in the London business unit cannot see accounts owned by the Sydney team. That boundary is well understood and well configured. But SharePoint does not know anything about D365 business units, security roles, or record ownership. SharePoint uses its own permission model — site collections, permission levels, groups — and by default, the document libraries created by the D365 integration inherit permissions from the parent SharePoint site.

This means a user with read access to the SharePoint site can browse document libraries directly via SharePoint Online, see folder names that correspond to account or opportunity names, and open files — even if they have zero access to those records in Dynamics 365. The CRM is not the gatekeeper for the documents. SharePoint is. And SharePoint was never told about your D365 security model.

The risk compounds in organisations where SharePoint is used broadly. Marketing teams, IT staff, interns on project sites — anyone with inherited site access potentially has document visibility that violates your intended data segregation. From a SOC 2, ISO 27001, or GDPR standpoint, this is not a theoretical risk. It is a demonstrable control failure.

Mapping D365 Security Architecture to SharePoint — Before You Choose a Tool

The most expensive mistake organisations make is reaching for a technical solution before they have mapped the architectural problem. Before any configuration decision, IT architects need to answer three structural questions:

1. What Is Your D365 Security Hierarchy?

Dynamics 365 enforces security through a layered model:

• Business Units — the primary organisational container. Records are owned by a business unit, and access cascades up and down the hierarchy based on role configuration.
• Security Roles — define what a user can do (read, write, delete, share) at what scope (user, business unit, parent business unit, organisation).
• Teams — records can be owned by teams rather than individual users, enabling cross-business-unit access without role elevation.
• Record Sharing — ad-hoc access grants that sit outside the standard role model and are notoriously difficult to audit.

Each of these layers needs a SharePoint equivalent. If your D365 security model has five business units with distinct data boundaries, you need five distinct SharePoint permission structures — not one inherited site with open access.

2. What Is Your Document Sensitivity Classification?

Not all documents attached to D365 records carry the same risk. A marketing brochure attached to an account record is different from a signed NDA or a case resolution note containing personal health information. Before architecting permissions, classify your document types and map them to risk tiers. This classification directly informs whether you need record-level permission granularity or whether library-level segregation is sufficient.

3. Who Needs SharePoint Access Independent of D365?

In most organisations, some legitimate SharePoint users genuinely need document access without D365 licences — legal reviewers, external auditors, compliance officers. Identifying these personas upfront prevents you from building a permission model that either over-restricts legitimate workflows or creates carve-out exceptions that undermine the entire architecture.

Only once you have clear answers to these three questions should you evaluate implementation approaches.

Evaluation Matrix: Three Approaches to Permission Sync

IT Managers evaluating their options broadly have three categories of solution. Here is an honest assessment of each.

Option 1: Native Configuration (SharePoint Permission Inheritance)

The default integration offers no automatic permission sync. You can manually manage SharePoint site, library, and folder permissions to approximate D365 boundaries, but this is a static configuration that does not respond to D365 changes — new users, role changes, record ownership transfers, business unit restructures.

• Maintenance burden: Very high. Every D365 change requires a manual SharePoint update.
• Audit traceability: Poor. No automated log of permission changes correlated to D365 events.
• Cost: Low licensing cost, high operational cost.
• Suitable for: Very small organisations with simple, stable security models and dedicated admin capacity.

Option 2: Power Automate-Based Permission Sync

A custom Power Automate solution can listen for D365 events — record creation, ownership change, team assignment, user deactivation — and trigger corresponding SharePoint permission updates via the SharePoint REST API or Microsoft Graph.

// Example: Power Automate HTTP action to set SharePoint folder permissions
// Triggered when D365 record ownership changes

POST https://graph.microsoft.com/v1.0/sites/{site-id}/drives/{drive-id}/items/{folder-id}/invite

{
  "requireSignIn": true,
  "sendInvitation": false,
  "roles": ["read"],
  "recipients": [
    { "email": "newowner@contoso.com" }
  ]
}

This approach is genuinely powerful when implemented well, but the architecture must account for failure scenarios, retry logic, and the latency between a D365 event and the SharePoint permission update taking effect.

• Maintenance burden: Medium. Flows require ongoing maintenance as D365 schema or business logic evolves.
• Audit traceability: Good, if flows are designed to write to a log table or Dataverse custom entity on every permission action.
• Cost: Medium. Power Automate licensing plus development and maintenance investment.
• Suitable for: Mid-market organisations with dedicated Power Platform capability and a willingness to own a custom solution.

Option 3: Third-Party Permission Replicators

Several ISV solutions in the Microsoft ecosystem offer automated D365-to-SharePoint permission synchronisation as a managed product. These tools typically poll D365 for security model changes and replicate them to SharePoint on a schedule or in near-real-time.

• Maintenance burden: Low operational burden once configured, but vendor dependency is a long-term strategic consideration.
• Audit traceability: Varies significantly by vendor. Evaluate whether the tool produces its own audit log and whether that log is exportable to your SIEM.
• Cost: Higher licensing cost, lower internal development cost.
• Suitable for: Organisations that need faster time-to-compliance, lack internal Power Platform development capacity, or operate in heavily regulated industries where a vendor's compliance certifications add value.

The honest verdict: There is no universally correct answer. The right approach depends on your organisation's internal capability, risk tolerance, audit requirements, and budget. Any consultant who tells you there is only one option is selling you something.

The CISO Compliance Checklist: 8 Questions Before Sign-Off

Whether you are presenting to your CISO, preparing for a SOC 2 audit, or documenting controls for ISO 27001 certification, these eight questions define the minimum bar for a defensible Dynamics 365 document storage architecture.

1. Can a SharePoint-licensed user access D365-originated documents without a corresponding D365 security role? If the answer is yes, you have a control gap. Document it, risk-rate it, and remediate it.
2. Does your permission model respond dynamically to D365 user deactivation? When a user is disabled in D365 or Azure AD, are their SharePoint document permissions revoked automatically and immediately?
3. Is there an auditable log of every permission change correlated to a D365 business event? SOC 2 Type II and ISO 27001 both require evidence of access control effectiveness over time — not just a point-in-time snapshot.
4. How are record-sharing exceptions in D365 reflected in SharePoint? Ad-hoc D365 record sharing is the most common source of permission drift. Does your architecture handle it?
5. Does your architecture address GDPR data subject access requests for documents? If a data subject requests all records held about them, can you locate and produce SharePoint documents linked to their D365 records without manual hunting?
6. What is your data residency configuration? Where D365 and SharePoint tenants are configured matters for GDPR cross-border transfer compliance. Confirm your SharePoint site is provisioned in the correct geographic region.
7. Have you tested permission boundaries with a non-privileged test account? Policy documentation is not a control. Demonstrated, tested access restriction is a control. When was your last permission boundary test?
8. Is your document storage architecture included in your incident response plan? If a SharePoint permission misconfiguration is discovered, what is the containment, notification, and remediation process? GDPR Article 33 requires breach notification within 72 hours if personal data is involved.

Building the Architecture Your Organisation Actually Needs

The Dynamics 365 and SharePoint integration is genuinely powerful when it is implemented with security architecture as a first-class concern — not an afterthought. The organisations that get this right are not necessarily the ones with the biggest budgets or the most sophisticated tooling. They are the ones that mapped their D365 security model to their SharePoint permission model on paper before writing a single line of configuration.

At CRMONCE, we work with IT leaders across India and globally to design governance frameworks that make compliance auditable and security boundaries enforceable — not just documented. If your organisation is running the default D365 SharePoint integration without a validated permission architecture, the silent security gap described in this post almost certainly applies to you.

The right time to close that gap is before your next audit finds it for you.

This post is part of CRMONCE's Power Platform Governance content series. For related reading, explore our guides on Power Platform Governance Blueprint and Dynamics 365 Audit Log Retrieval. For a personalised architecture review, contact the CRMONCE team.