Dynamics 365 系统集成：从业务流程出发的规划与落地指南

Dynamics 365 系统集成，就是让 Dynamics 365 与 ERP、财务、邮件、呼叫中心、电商、营销等系统自动交换客户、订单、发票、服务工单等数据，并让跨系统的业务流程连续运行，不再依赖人工导出、复制和核对。决定集成成败的，往往不是选哪一个连接器或 API，而是集成之前有没有把业务流程、数据归属和治理规则讲清楚。因此，对于正在扩张、系统数量不断增加的企业，更稳妥的做法是先梳理流程、再设计接口、最后配置技术。由同时熟悉 Dynamics 365、Power Platform 和业务流程自动化的实施团队主导这一工作，可以从项目第一天起把数据完整性和后期维护纳入设计。BetterS Agency 的定位正是如此：以业务流程为核心，而不只是部署软件。

关键要点

• Dynamics 365 集成可分为用户界面集成、数据集成和流程集成三类，不同类型对实时性、数据量和错误处理的要求差别很大。
• 集成前应先画出应用集成图，明确哪些系统需要对接、交换什么数据、频率和数据量多大，以及谁对每一类数据负责。
• Dual-write、数据管理框架（DMF）、OData/Web API、Power Automate 加 Azure 服务等方式各有适用场景，应按业务需求而非技术偏好选择。
• 安全、权限、日志和告警必须在设计阶段确定，而不是上线后再补。
• 集成上线只是开始：持续监控、数据管理员机制和版本管理，决定系统能否长期保持准确与可用。

目录

• Dynamics 365 系统集成到底连接什么
• 集成之前：先梳理流程、系统与数据治理
• 常见集成方式及适用场景
• 分步实施：从设计文档到上线
• 安全、权限与错误处理
• 上线之后：监控、维护与扩展
• 常见失败原因与降险方法
• BetterS Agency 如何承接 Dynamics 365 集成项目
• 我们的观点
• 常见问题
• 来源

Dynamics 365 系统集成到底连接什么

按照 Microsoft 的定义，CRM 集成会把 CRM 与其他持有客户数据的业务应用连接起来，例如 ERP、电子邮件、联络中心、电商和营销工具，使联系人、客户、订单、发票、服务案例以及相关工作流在系统之间自动流动。对于企业管理层而言，这意味着销售看到的订单状态与财务看到的开票状态来自同一数据来源，而不是两份需要月底对账的表格。

从架构角度看，Microsoft Learn 将 Dynamics 365 的集成场景分为三类：

• 用户界面（UI）集成：在一个系统的界面中直接呈现另一个系统的信息或操作，用户不必切换应用。
• 数据集成：两个系统处理同一份数据的不同表示，典型例子包括营销资产同步、银行账户对账、订单状态更新、汇率更新和客户数据同步。
• 流程集成：一个业务流程跨越多个系统，例如商机赢单后自动在项目或财务系统中创建项目与合同。

在数据层面，Microsoft Learn 的数据管理架构指南把业务数据分为主数据、配置数据、交易数据和推断数据：主数据包括公司、联系人、客户、供应商和产品；配置数据包括币种、税码、付款方式和地址信息；交易数据包括沟通记录、银行交易以及采购订单等 ERP 交易。同一份指南还指出，数据集成通常通过事件触发（记录创建或更新时）或按计划批量执行。这一分类非常实用：主数据需要明确的唯一来源和清洗规则，交易数据更关注时效和数量，配置数据则必须在各系统之间保持一致，否则一个税码差异就可能让整条订单同步失败。

集成之前：先梳理流程、系统与数据治理

很多集成项目在技术上并没有失败，失败的是业务假设。例如销售团队以为客户编号由 CRM 生成，财务团队却坚持以 ERP 为准，结果两边各自创建记录，重复客户在数月后才被发现。为了避免这种情况，集成前的梳理至少应覆盖以下几方面。

明确集成的业务理由

Microsoft Learn 列出的集成动因包括：保留遗留系统、分阶段上线 Dynamics 365、满足法规要求、合并财务数据、管理多种架构，以及为专业报表提取数据。每一个接口都应能对应到其中至少一个业务理由，否则它很可能是不必要的复杂度。同一指南建议，详细蓝图应从一张应用集成图开始，标明哪些系统需要集成以及数据交换的性质，然后逐步补充接口触点、频率、数据量以及与应用生命周期管理（ALM）资源的关联。

评估两端的影响

Microsoft Learn 的项目治理指南要求，集成治理应评估双方系统的业务影响、数据交换约定、非 Dynamics 365 系统的安全与技术影响，以及数据量和性能等非功能需求，并建立处理来自其他系统问题的流程。换言之，集成不是 Dynamics 365 团队单方面的工作，ERP、财务或第三方系统的负责人必须参与约定。

建立数据归属与数据管理员机制

Microsoft Learn 将数据管理员（data steward）定义为负责数据资产管理与监督的角色，其目标是以可用、安全、可信的方式提供数据。指南同时强调，数据质量位于数据治理政策的首位，最熟悉数据的业务用户应成为清洗工作的把关人。在实践中，这意味着为客户、产品、价格等每一类主数据指定一位业务负责人，并在集成上线前完成去重、标准化和字段规则确认。

常见集成方式及适用场景

选择集成方式时，应先回答三个问题：数据需要多实时？单次和每日的数据量有多大？出错时谁来处理、如何重试？Microsoft Learn 的 TechTalk 指南介绍了几种主流方式：Dual-write 用于财务与运营应用和 Dataverse 之间的实时双向同步，数据管理框架（DMF）用于批量导入导出，OData/Web API 则支持基于 REST 的增删改查操作，包括实时集成场景。

对于需要可靠出入站接口的场景，Microsoft Learn 迁移到 Dynamics 365 Sales 的参考架构给出了一条清晰路径：出站方向由 Dataverse 表上的 Power Automate 云端流触发，经启用会话的 Azure Service Bus 队列，交给以托管标识保护的 Azure Function 处理，凭据存放在 Azure Key Vault，日志写入 Application Insights；入站方向使用 OAuth2 凭据、会话感知的 Service Bus 队列以及 Dataverse Upsert 请求。这种设计的价值在于：消息排队保证了顺序与可重试，Upsert 避免了重复记录，集中日志让每一次失败都可追溯。

制造企业在 CRM 与 ERP 之间选择方案时，常常需要在原生同步、中间件和定制接口之间权衡，可参考 CRM 与 ERP 集成方案对比，结合自身订单和库存流程判断。

分步实施：从设计文档到上线

以下步骤适用于大多数 Dynamics 365 集成项目，每一步都列出了常见失误。

1. 定义业务目标。 Microsoft Learn 的集成策略与治理检查清单首先要求用业务人员能够理解的语言写下集成目标。常见失误是只写“同步客户数据”，却没有说明同步是为了让销售看到信用额度还是为了让财务自动开票，两者对应的字段、频率和优先级完全不同。BetterS Agency 的 CRM 策略与架构服务正是从这一层开始，先厘清流程，再决定系统如何承载。

2. 绘制应用集成图并选定模式。 在图上标明每个接口的方向、触发方式、频率和数据量，再按检查清单的要求，选择与数据量、频率和服务保护限制相匹配的模式，并决定是否引入集成中间件或消息服务。常见失误是对所有接口都使用同一种方式，导致小接口过度设计、大接口性能不足。

3. 编写功能与技术设计文档。 Microsoft Learn 的功能与技术设计文档模板涵盖项目范围、组织结构、业务流程、架构、安全、报表、每个接口的集成设计以及数据迁移，并在需要时为每个来源提供字段级映射。字段映射是最容易被低估的环节：选项集取值、币种精度、地址格式和必填字段的差异，都会在测试阶段集中暴露。

4. 配置与开发。 在开发环境中完成连接、映射和业务规则配置，所有定制内容都应纳入 ALM 和版本控制，这同样是检查清单中的明确要求。BetterS Agency 的定制开发与集成、Power Platform 定制服务在这一阶段承担接口开发与自动化工作流搭建。

5. 数据迁移与清洗。 项目治理指南要求迁移数据符合用途、干净、安全且及时，在关键里程碑提供正确类型、数量和质量的数据，并让模拟切换尽量贴近正式上线时的迁移。常见失误是只用少量样本数据测试，正式迁移时才遇到历史数据中的异常格式。

6. 测试。 检查清单建议在接近真实的条件下测试每一个集成的用户体验和性能。除了正常路径，还应测试网络中断、目标系统不可用、重复提交和超大批次等异常情况，并确认告警能送达正确的人。

7. 上线与切换。 按演练过的切换计划执行，明确回滚条件和上线后首周的支持安排。BetterS Agency 的采用与赋能服务在这一阶段帮助各业务团队理解新的数据流和操作方式，让集成真正被使用。

安全、权限与错误处理

集成接口本质上是系统之间的“服务账户”，其权限往往比普通用户更大，因此必须单独设计。Microsoft Learn 的 TechTalk 指南建议使用 Microsoft Entra ID 进行身份管理，以 OAuth 保护 API 通信，以 Azure Key Vault 管理密钥和证书，数据传输使用 HTTPS 与 TLS 1.2 加密，并遵循相关数据保护法规。对于美国的保险、法律等受监管行业，接口能访问哪些字段、日志保存多久、谁可以查看传输内容，都应在设计文档中写明。

错误处理同样需要事先设计，而不是依赖人工发现。一个成熟的集成方案通常包括：

• 集中日志：每条消息的来源、目标、时间和结果都可查询，同一份指南建议结合 Application Insights 与集中日志进行监控。
• 自动重试与死信队列：暂时性错误自动重试，持续失败的消息进入单独队列等待处理，而不是静默丢失。
• 异常复核流程：为业务人员提供清晰的异常清单和处理入口。制造企业可参考 CRM 与 ERP 集成异常复核自动化的做法，把异常处理变成有负责人、有时限的日常流程。
• 最小权限：集成账户只授予完成任务所需的表和字段权限。

上线之后：监控、维护与扩展

集成系统最常见的问题不是上线当天出错，而是在几个月后逐渐失效：某个字段被业务部门改名，某个流程被个人复制修改，某个接口的数据量翻倍后开始超时，却没有人收到告警。要避免这种缓慢衰退，上线后的运营需要与上线前的设计同样严谨。

• 持续监控与告警。 检查清单要求集成平台具备监控、审计、通知和告警能力。实际运营中，应为每个接口设置成功率、延迟和积压量阈值，并把告警发送给明确的负责人。
• 数据管理员的日常职责。 项目治理指南强调要建立数据管理员流程，使数据在项目期间和项目结束后都保持干净。可以按月复核重复记录、空值比例和同步失败率，并将结果纳入管理例会。
• 变更管理与版本控制。 任何字段、表结构或流程变更，都应通过 ALM 流程评估对接口的影响，并在测试环境验证后再发布。
• 为增长预留容量。 Microsoft 面向制造业销售的参考框架指出，实时集成的可扩展性可依靠 Azure Service Bus 与 Azure Functions 支撑，而复杂的数据集成需要稳健的错误处理和分阶段部署。新增业务线或系统时，应沿用同一套架构和治理规则，而不是另起炉灶。
• 用数据验证业务价值。 借助 Power BI，把订单同步时效、开票周期、异常处理时长等指标可视化，管理层可以直接看到集成带来的流程改善，也能更早发现退化趋势。

常见失败原因与降险方法

上述制造业参考框架列出的关键考量，几乎覆盖了集成项目最常见的风险：Dynamics 365、Power Platform 与 Azure 服务的许可与成本管理，基于 Microsoft Entra 身份和 Azure Key Vault 的安全与合规，实时集成的可扩展性，需要稳健错误处理和分阶段部署的数据集成复杂度，以及面向多类干系人的用户采用与培训。结合这些考量，可以归纳为以下对照：

对于以项目交付为核心的企业，集成往往需要贯穿商机、报价、项目和回款全过程，可参考项目运营自动化流程设计指南，从端到端流程的角度规划各系统之间的交接点。

BetterS Agency 如何承接 Dynamics 365 集成项目

BetterS Agency 专注于 Microsoft Dynamics 365 与 Power Platform 的实施与定制，服务覆盖销售、客户服务、项目运营、客户洞察及现场服务模块，并提供定制开发与系统集成、业务流程自动化（支持 UiPath、n8n、Zapier、Make.com 等平台）、Copilot 与 AI 解决方案、CRM 策略与架构、治理与数据完整性、采用与赋能以及 Power BI 数据智能。服务行业包括保险、法律、制造、建筑和专业服务等，项目按需求和阶段报价，不采用订阅收费；已公布价格的套餐中，Dynamics 365 Sales CRM 一次性费用 1,495 美元起，Dynamics 365 Project Operations 一次性费用 2,995 美元起。

希望把现有系统与 Dynamics 365 打通的企业，可以在BetterS Agency 服务页面了解集成、自动化与治理服务的范围，或在实施套餐页面查看各模块套餐。保险机构可另行参阅面向保险代理机构的 Dynamics 365 方案。

我们的观点

在我们看来，Dynamics 365 系统集成首先是一项业务流程工程，其次才是技术工程。连接器、API 和 Azure 服务都已经足够成熟，真正拉开项目差距的，是集成之前有没有回答清楚“哪个系统对哪类数据负责”“流程在哪一步交接”“出错时谁来处理”这三个问题。

这也是我们坚持以业务流程为核心、而不只是部署软件的原因。当系统设计贴合组织的实际运作方式，集成接口就成为流程的自然延伸，员工愿意使用，数据自然保持一致；当集成只是把字段从一端搬到另一端，问题会在几个月后以重复记录、对不上的报表和绕开系统的电子表格形式重新出现。

因此，我们把治理与数据完整性放在每个集成项目的设计阶段：明确数据归属、字段规则、日志与告警，并将所有定制纳入版本管理。对于保险、法律、制造、建筑和专业服务这类流程复杂、系统众多的行业，这样的基础能显著降低后期系统损坏和配置不规范的风险，让 Dynamics 365 与 Power Platform 随业务增长持续扩展，而不是每扩一次就重建一次。

Derek

常见问题

Dynamics 365 系统集成一般需要多长时间？

周期取决于接口数量、数据质量和涉及的系统复杂度。一个只连接 CRM 与单一 ERP 的核心接口，和一个涵盖迁移、多系统流程集成及报表的项目，工作量差别很大。较稳妥的做法是先完成集成图和设计文档，再据此确定分阶段计划和里程碑。

Dual-write 和 Power Automate 应该如何选择？

Dual-write 面向 Dynamics 365 财务与运营应用和 Dataverse 之间的实时双向同步，适合客户、产品、订单等需要两端保持一致的数据。Power Automate 更适合事件触发的流程集成，配合 Azure Service Bus 和 Azure Functions 可以处理需要排队、重试和审计的接口。很多项目会同时使用两者，各自承担最适合的场景。

集成上线后数据出现不一致怎么办？

首先通过集中日志定位失败的消息和对应记录，判断是映射规则、主数据冲突还是目标系统暂时不可用。随后由该类数据的数据管理员确认正确值，并修正规则以防再次发生。长期来看，应为同步失败率和积压量设置告警，让问题在影响业务之前被发现。

已经在用其他自动化平台，还能与 Dynamics 365 集成吗？

可以。BetterS Agency 搭建的自动化工作流支持 UiPath、n8n、Zapier、Make.com 等平台，可以与 Dynamics 365 和 Power Platform 协同工作。关键是把这些流程纳入统一的治理和监控，避免分散在各个团队中无人维护。

来源

• What Is CRM Integration? | Microsoft Dynamics 365
• 为 Dynamics 365 应用选择正确的集成设计 | Microsoft Learn
• Manage your data effectively with the right architecture | Microsoft Learn
• Align your Dynamics 365 integration with business goals | Microsoft Learn
• Govern key project areas in your Dynamics 365 implementation | Microsoft Learn
• Manage your data in Dynamics 365 implementation projects | Microsoft Learn
• TechTalk: General guidance for integrating Dynamics 365 apps | Microsoft Learn
• Key considerations for migrating to Dynamics 365 Sales | Microsoft Learn
• Integration strategy and governance checklist | Microsoft Learn
• Create a functional and technical design document | Microsoft Learn
• Dynamics 365 Azure-powered manufacturing sales framework | MicrosoftDocs on GitHub

推荐

• Dynamics 365 项目运营技术指南
• Dynamics 365 业务流程
• Dynamics 365 项目运营工作流实施
• Dynamics 365 财务与运营实施指南