Dynamics crm 在从沙箱到产品的解决方案中部署业务单元和安全模型

我正在从事一个Dynamics 365项目（v9.1），该项目有几个使用沙盒（如DEV）的组织环境，然后是一些其他沙盒（如QA），最后是PROD（例如）

我被告知，对业务部门的任何安全角色更改都必须在每个环境中手动执行

我被告知这样做的原因是，当创建环境时，默认的父业务单元名称由Dynamics 365在默认情况下唯一生成，这导致每个环境具有不同的父业务单元GUID，这会对子业务单元、团队等产生不利影响，因此，每个环境的安全模型必须针对每个环境手动完成

我对Dynamics 365非常陌生，但从直觉上看，Dynamics 365要求我在每个环境上手动进行安全更改（而不是将其封装在开发人员的解决方案中）似乎并不正确

我的问题是：

为什么沙盒默认父业务单元GUID与PROD不同

正确的方法是什么，这样我只需要在DEV sandbox上更改业务部门、团队和安全角色，然后作为解决方案导出/部署到PROD

---

这是正确的，因为业务单元是一个实体记录，并且当使用与组织名称相同的名称设置组织时，将创建默认的父业务单元

• 在目标系统中维护与源系统相同的业务单元层次结构
• 在目标系统中保留与源系统相同的业务单元ID（GUID）值（根业务单元除外）

根业务部门是上述目标的一个例外，因为 它是在创建CRM组织时自动创建的 供应。一旦创建了根业务单元，就没有办法了 更改it主键（businessunitid）的ID（GUID）值 字段）。换言之，根业务单元始终具有 两个不同CRM组织的不同ID

应该通过初始部署策略（如技术）来修复

如果是内部部署，请使用部署管理器复制生产数据库并创建较低的区域实例

如果是CRM online，我们可以进行产品刷新，完全刷新（模式+数据）最好一次。稍后，仅在需要时刷新模式

通过这种方式，我们可以确保较低区域的更改（具有角色、自定义等的解决方案）可以移动到QA/PROD，而无需担心非同步环境

---

BU，团队不能作为解决方案的一部分进行移植，因为它们是表记录，使用数据迁移实用程序或使用CSV格式以相同GUID导出/导入都可以。我的回答有用吗？是的，我向团队提供了一个自动化解决方案。非常感谢。