在Dynamics 365中设置SharePoint的集成度

Dynamics 365 客户互动中包含了一个基于服务器的原生 SharePoint 集成。配置完成后，用户可以在 Dynamics 365 记录中访问文档，同时将实际文件存储在 SharePoint 中，而非 Dataverse 中。.

对于典型的 Dynamics 365 和 SharePoint 在线环境，其配置主要包括五个步骤：

1. 启用基于服务器的 SharePoint 集成
2. 连接您的 SharePoint 网站
3. 为所需的 Dynamics 365 表启用文档管理
4. 选择 SharePoint 文件夹结构
5. 分别从 Dynamics 365 和 SharePoint 测试集成情况

设置过程本身相对简单。需要多花些心思的部分是安全性。.

Dynamics 365 和 SharePoint 具有 独立的权限模型. 原生集成并不会自动使 SharePoint 文档权限遵循 Dynamics 365 记录的访问权限。如果需要让文档访问权限遵循相应的 Dynamics 365 记录，则需单独进行配置。.

本文首次发布于2020年8月，最后更新于2026年9月。.

该原生集成将 Dynamics 365 客户互动应用（如销售和客户服务）与 SharePoint 文档管理系统连接起来。.

用户可以打开“账户”、“联系人”、“商机”、“服务单”或其他已启用表中的“文档”区域，并对与该记录相关的文档进行操作。文件本身存储在 SharePoint 中，您可以在其中使用 SharePoint 的各项功能，例如版本历史、协作和文档元数据。.

这形成了一种简单的职责划分：

• Dynamics 365： 业务记录及其与文档位置的关系
• SharePoint： 文档本身以及 SharePoint 的文档管理功能

附件是一个重要的例外。已存储在 Dataverse 中的笔记和电子邮件附件不会仅仅因为启用了集成就自动迁移到 SharePoint。要迁移这些内容，需要单独的流程或解决方案。.

在打开设置向导之前，有几项决定值得提前做出。.

对于 SharePoint Online，您的 Dynamics 365 环境和 SharePoint 站点必须位于同一个 Microsoft 365 租户中。当您配置 SharePoint 站点时，Microsoft 会对此进行验证。.

此外，您还需要在 Dynamics 365 和 SharePoint 中具备相应的管理权限。微软目前的文档中规定，配置文档管理需要“系统管理员”或同等权限，而启用 SharePoint 集成则需要“全局管理员”权限。.

您想要使用的 SharePoint 站点应已存在。.

不要仅仅因为可以，就在所有地方都启用文档管理。.

典型的候选人包括：

• 帐户
• 联系我们
• 机遇
• 案例
• 名言
• 项目或自定义表

从确实需要文档的表开始，可以使生成的 SharePoint 结构更易于理解和管理。.

在设计 SharePoint 结构之前，请先问一个问题：

如果某人失去了对某条Dynamics 365记录的访问权限，是否也应失去对其相关文档的访问权限？

如果答案是“是”，那么权限问题绝不能事后再考虑。设置完成后，我们会再回到这个问题上。.

目前最明确的操作路径是通过 Power Platform 管理中心。.

转到：

管理 → 环境
（请选择您的环境）
设置 → 集成 → 文档管理设置

选择 启用基于服务器的 SharePoint 集成.

向导将打开，并引导您完成连接的启用。微软当前的文档采用了此 Power Platform 管理中心路径。.

基于服务器的集成是微软目前针对 Dynamics 365 和 Dataverse 模型驱动型应用程序所采用的 SharePoint 文档管理方案。.

向导询问您的 SharePoint 站点位于何处。.

对于标准的 Microsoft 365 部署，请选择 在线咨询.

请输入您希望 Dynamics 365 使用的 SharePoint 网站的 URL，例如：

https://yourtenant.sharepoint.com/sites/yoursite

Dynamics 365 会验证 URL。对于 SharePoint Online，它还会验证该网站是否属于同一个 Microsoft 365 租户。.

如果验证失败，请先检查基本事项：

• 这个网址正确吗？
• 这个网站存在吗？
• 管理员可以访问它吗？
• SharePoint 站点是否位于正确的租户中？

该集成方案可支持多个 SharePoint 站点，但保持初始设计简单通常能使管理更轻松。.

启用基于服务器的集成后，请返回 文档管理设置.

选择需要启用 SharePoint 文档管理的 Dynamics 365 表。.

例如

• 账户
• 联系我们
• 机遇
• 案例
• 铅

Microsoft 允许您针对特定表启用文档管理功能，因此无需从一开始就对所有表都启用该功能。.

如果需求发生变化，您可以稍后回来添加其他表格。.

接下来，请验证您的 SharePoint URL，并选择 Dynamics 365 应如何组织文档位置。.

标准配置允许您选择围绕选定的父表来组织文档位置，例如 账户 或 联系我们, ，或者采用更扁平化的组织结构。. 

一种基于……的结构 账户 可能会产生与以下内容在概念上相似的结果：

账户 / Contoso / 联系人 / John Smith

A 联系我们基于……的结构则会主要围绕“联系人”来组织文档。.

如果您未选择父表结构，则记录文件夹可以并列排列，形成更扁平的结构。.

Dynamics 会在文件夹名称中添加标识符，以确保文档位置的唯一性。虽然直接浏览 SharePoint 时这些标识符看起来可能不太美观，但它们能防止两个名称完全相同的 Dynamics 记录发生冲突。.

在确定结构之前，请考虑用户将如何在Dynamics 365之外查找文档。一种在只有50个账户时看起来还算合理的设计，当账户数量达到50,000个时，可能会显得不方便。.

完成向导，让 Dynamics 365 创建所需的 SharePoint 文档位置。.

即使向导显示操作成功，也请不要停止。.

为已启用的某张表创建一个 Dynamics 365 记录，然后转到 证件.

上传一份测试文档。.

请确认：

• “文档”区域已启用；;
• 文件已成功上传；;
• 该文档存储在 SharePoint 中；;
• 已创建预期的 SharePoint 文件夹。.

然后直接转到 SharePoint 并查找相同的文档。CRM 软件博客中的设置分步指南将此作为基本的验证流程。.

不过，对于生产环境，请再增加一项测试：使用具有代表性的用户进行测试，而不仅仅是管理员。.

例如，使用：

• 一名记录持有者；;
• 通过团队获得访问权限的用户；;
• 一个只读用户；;
• 一个本不应有权访问该记录的用户。.

通过 Dynamics 365 和 SharePoint 直连链路测试访问情况。.

第二次测试之所以重要，是因为它揭示了原生集成的最大局限性。.

Dynamics 365 和 SharePoint 并未采用统一的授权模型。.

Dynamics 365 和 Dataverse 可以利用以下因素来确定记录的访问权限：

• 安全角色；;
• 业务部门；;
• 记录所有权；;
• 所有者和访问团队；;
• 记录共享；;
• 层次结构安全。.

SharePoint 分别控制对其站点、库、文件夹和文档的访问权限。.

原生集成不会自动同步这两个安全模型。这也是 Dynamics 管理员在 Microsoft 社区中提出的问题：即用户即使在 Dynamics 365 权限中已无权访问相关记录，仍有可能通过 SharePoint 访问该文档。.

例如，假设某个账户的所有者发生变更，导致销售人员在Dynamics 365中无法再访问该账户。.

如果该销售人员对相应的文档位置仍拥有 SharePoint 权限，那么仅更改 Dynamics 365 所有权并不会自动撤销 SharePoint 访问权限。.

也可能出现相反的情况。用户可能拥有对 Dynamics 365 记录的权限，但在打开其文档时却收到访问错误，因为 SharePoint 未授予必要的访问权限。.

这并不意味着微软的集成出现了故障。这意味着这两个平台仍然采用各自独立的授权系统。.

对于简单且稳定的安全需求，定制自动化可能是一种合理的方法。.

例如，您可以创建一条规则，授予商机所有者对相应 SharePoint 文件夹的访问权限，同时还授予一个预定义的销售组访问权限。.

当你尝试重现该情况时，问题就出现了 有效访问 Dynamics 365, ，而不是一条简单的规则。.

您的自动化流程可能需要考虑以下因素：

• 所有权变更；;
• 团队成员资格；;
• 记录被共享和取消共享；;
• 安全角色的变更；;
• 业务部门的变动；;
• 权限撤销以及权限授予。.

自定义实现还需要包含故障处理、监控和对账功能。如果自动化流程在授予访问权限时成功，但在随后应撤销该访问权限时却失败，则用户可能会比预期更长时间地保留对文档的访问权限。.

这就是为什么自定义的 Power Automate 流程在针对刻意设计的简单权限模型时能运行良好，但当需要 SharePoint 访问权限持续与 Dynamics 365 安全策略保持一致时，其维护难度就会显著增加。.

对于必须满足该对齐要求的环境，, CB Dynamics 365 to SharePoint Permissions Replicator 旨在将 Dynamics 365 中的相关访问权限变更复制到相应的 SharePoint 文档位置。.

另一个架构方面的考虑因素是，有多少个文件夹拥有独立的权限设置。.

一种方法是为每个 Dynamics 365 记录创建一个单独的文件夹，并为该文件夹分配唯一的权限。从技术上讲，这种方法可行。但在大规模部署时，则需要进行周密的规划。.

SharePoint Online 最多支持 每个列表或库最多支持 50,000 个唯一的权限范围, ，微软建议将该数值控制在 5,000 以获得最佳性能。.

如果您预计会有数万条 Dynamics 记录，请不要假设在单个库中，每条记录对应一个唯一受保护的文件夹这种方案能够无限扩展。.

在可能的情况下：

• 使用继承的权限；;
• 将“组”用于稳定的用户集合；;
• 在架构上合理的情况下，将内容划分为不同的库或站点；;
• 在正式上线前，估算唯一受保护位置的数量。.

如果您需要比微软标准的 Dynamics 365 文档位置结构更规范的 SharePoint 层次结构，可以采用如下这种配置方法： SharePoint Structure Creator 可以始终如一地创建所需的文件夹和库。.

文件夹结构和权限是相关的设计决策，但它们解决的问题不同。仅靠建立更好的层次结构，并不能使 SharePoint 权限与 Dynamics 365 保持一致。.

在向用户发布该集成之前，请确认以下事项：

• 所连接的 SharePoint 站点和文档库符合 Dynamics 365 文档的保密级别和协作要求；;
• 该文件夹结构已获得利益相关方的批准，并针对预期的“账户”、“联系人”和“文档”数量进行了验证；;
• 已对具有代表性的用户进行了测试；;
• 已对 SharePoint 的直接访问以及 Dynamics 365 的访问进行了测试；;
• 已考虑了数据保留、对外共享以及其他 SharePoint 治理要求；;
• 您已决定SharePoint文档访问是否必须紧随Dynamics 365记录访问之后；;
• 如果需要权限对齐，已对授予和撤销访问权限两种情况进行了测试；;
• 系统上线后，由某人负责监控和故障排查。.