这是我的第494篇原创文章，写于2023年6月8日。
2021年11月2日，Power Apps博客的博文 Announcing Public Preview for modernize business units 宣布了Modernized Business Units开启Public preview阶段，到本文写作时，这个Feature已经General Available了。相关功能介绍请参考官方文档 Security concepts in Microsoft Dataverse 的 Matrix data access structure (Modernized Business Units) 章节，有个视频 First look at Modernized Business Units in Microsoft Dataverse 讲得不错，我将其转载到我的B站了，观看请点击 此链接。
为了方便解说和测试，我建立了如下结构的Business Unit。
我从最小的能使用App的角色克隆一个角色出来，打开 Power Platform Admin Center，选择对应的环境，点击 Users + permissions 下面的Security roles链接。
我将标准的默认最小访问权限的 App Opener角色Copy出来一个，命名为UserPrivileges名称，再Copy一个出来命名为 BUPrivileges，还Copy了一个出来命名为ParentChildBUPrivileges，对于我要测试的实体Demo Entity分别是个人级别所有权限，业务部门级别，上下级业务部门级别所有权限。
创建的账号清单如下：
首先我用这些账号各创建了一条数据，可以看到列表界面是可以将 Owning Business Unit字段(字段逻辑名为owningbusinessunit)显示出来的，当然也可以显示到表单上。
在表单上显示的Owning Business Unit字段目前是只读的。
下面我们来启用这个功能，登录 Power Platform Admin Center，选择对应的环境，然后点击 Settings > Product > Features，将 Record ownership across Business Units 这个Feature设置为On，然后保存。
几分钟后就启用成功了，启用成功第一个发现就是Owning Business Unit字段(字段逻辑名为owningbusinessunit)可以编辑了，不像之前那样是锁定的了(官方原文是：Each record has an Owning Business Unit column which determines which business unit owns the record. This column defaults to the user’s business unit when the record is created and cannot be changed except when the feature switch is turned ON.)。如果是普通用户的话，需要用户的权限包括了对Business Unit这个表的Append To权限最小是Business Unit级别。
可以看到更改后记录的 Owning Business Unit的Business Unit可以和记录Owner的Business Unit不一样。
然后Owning Business Unit是BU2-2了，设置在这个BU2-2的用户testuser12登录也看不到这个记录，因为它的角色对这个表的读取权限是个人级别。但是如果给他BUPrivileges这个角色就可以看到并且编辑这个记录了，因为这个角色对Demo Entity表的权限是业务部门级。
另外一个变化就是在 Power Platform Admin Center 给用户授予角色时候的变化(注意在经典界面维护用户角色是不会有什么变化的)。点击 Settings > Users + permissions > Users
选择要更改角色的用户，点击 Manage security roles 按钮，可以看到右边窗口的 Business unit是可以选择的了。这时候我给他BU1这个Business Unit下的ParentChildBUPrivileges角色的话，
他就可以看到Owning Business Unit为BU1或者BU1下面的子Business Unit的所有记录了，当然了，他自己负责的记录依然可以看到并编辑。
对于创建记录时候设置Owning Business Unit为别的Business Unit，就需要用户在这个Owning Business Unit有一个角色且该角色包括了创建这个记录的权限，当然如果它有这个Owning Business Unit的上级Business Unit中的角色，且这个角色的对这个表的创建权限为上:下级业务部门或者组织级也可以，否则会报错，这是我测试的结果。比如我用testuser12创建Owning Business Unit为BU2的记录会报错，但是如果我给testuser12授予BU2这个Business Unit中的UserPrivileges角色后就不会报错了。比如我用testuser12创建Owning Business Unit为BU2-1的记录会报错，但是如果我给testuser12授予BU2这个Business Unit中的ParentChildBUPrivileges角色后就不会报错了。
如果报错下载的信息类似如下：
Exception Message:
Principal user (Id=93143126-1705-ee11-8f6e-6045bd571496, type=8, roleCount=4, privilegeCount=269, accessMode=0, MetadataCachePrivilegesCount=9377, businessUnitId=79d19439-0405-ee11-8f6e-6045bd571496),
is missing prvCreately_demoentity privilege (Id=08895282-263d-48a4-be73-4d037e6b22bb)
on OTC=10736 for entity 'ly_demoentity' (LocalizedName='Demo Entity')
in Business Unit: BU2-1 (Id=75d19439-0405-ee11-8f6e-6045bd571496).
context.Caller=93143126-1705-ee11-8f6e-6045bd571496
按照官方文档的说法，别的Business Unit的某个表的记录可以分派给只要有这个表的个人级别或者更高的读取权限的用户,前提是 EnableOwnershipAcrossBusinessUnits 这个设置是true，我看了下我的环境是的。可以使用工具 seanmcne/OrgDbOrgSettings 来查看，不想学习源码的话直接下载安装包，是一个托管解决方案，下载网址是：https://github.com/seanmcne/OrgDbOrgSettings/releases 。
按照官方文档的说法，还要将 RecomputeOwnershipAcrossBusinessUnits 参数设置为true (这个设置需要耗时5分钟左右，会对系统有影响请择时设置)，AlwaysMoveRecordToOwnerBusinessUnit 参数设置为false。
在将AlwaysMoveRecordToOwnerBusinessUnit 参数设置为false之前，如果你分派记录的话，记录的Owning Business Unit字段的值在分派的时候会自动更新为新Owner的Business Unit。设置为false之后，记录的Owning Business Unit字段的值就不会变化了，如下，虽然分派给了testuser12，这个用户的Business Unit是BU2-2，但是Owning Business Unit字段的值还是保持之前的BU2-1不变。当然，因为Owner是testuser12，他还是可以读写这个记录的，虽然这个记录的Owning Business Unit字段的值是BU2-1，testuser12用户并没有这个Business Unit负责记录的相关权限。
发现一个问题就是，如果我用 getGlobalContext.userSettings (Client API reference) 来查看自己的角色，发现会有遗漏。如下代码 Xrm.Utility.getGlobalContext().userSettings.roles 返回只有2个角色：
但是实际上我授予了这个testuser12总共3个角色，我用高级查询查出来的结果是对的，结果如下：
使用的FetchXml如下：
<fetch version="1.0" output-format="xml-platform" mapping="logical" distinct="true">
<entity name="role">
<attribute name="name" />
<attribute name="businessunitid" />
<attribute name="roleid" />
<order attribute="name" descending="false" />
<link-entity name="systemuserroles" from="roleid" to="roleid" visible="false" intersect="true">
<link-entity name="systemuser" from="systemuserid" to="systemuserid" alias="ab">
<filter type="and">
<condition attribute="domainname" operator="eq" value="[email protected]" />
</filter>
</link-entity>
</link-entity>
</entity>
</fetch>这个新的权限模型为减少共享，跨BU读写数据(特别是BU不在一个BU分支上)提供了更大的可能，值得研究使用，各位如果在实际使用中碰到什么问题或者好的最佳实践欢迎共享。