微软动态CRM专家罗勇 ，回复314或者20190311可方便获取本文，同时可以在第一间得到我发布的最新博文信息，follow me！我的网站是 www.luoyong.me 。

前面的博文 Dynamics 365 POA表记录的查询 讲了查看POA表的记录数，那这些记录怎么来的呢？我今天就根据文章 Excessive PrincipalObjectAccess Table Growth in CRM 4.0 from the Reparent – Cascade All Setting 来讲解下。

来源主要分为如下四个途径。

1. 记录更改Owner后和共享该的所有可能权限给该记录原来的Owner。这个行为会不会发生与一个系统管理配置项目有关，在【设置】>【管理】>【系统设置】中可以查看，默认是否的。如下图所示的【设置是否与原始负责人共享重新分派的记录】。

这样产生的记录的AccessRightsMask字段会有值(不会为0)，但是InheritedAccessRightsMask字段值为0。我修改后实际做了一个分派的例子，分派后在POA表的确创建了一条记录。可以看到该记录的AccessRightsMask字段值为 852023，PrincipalTypeCode值为8，因为是共享给个人。ObjectTypeCode的值为被共享记录对应实体的ObjectTypeCode，ObjectId为被共享记录的Id，PrincipalId为给想给的对象的Id。

如果继续分派给我自己的话，还会增加一条POA记录，共享权限给分派前的记录的Owner。我在分派给别人的话，不会增加给我自己的共享记录了，应该是修改。POA表有如下的唯一索引。

ALTER TABLE [dbo].[PrincipalObjectAccess] ADD  CONSTRAINT [UQ_PrincipalObjectAccess] UNIQUE NONCLUSTERED

(

    [PrincipalId] ASC,

    [ObjectId] ASC,

    [ObjectTypeCode] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 80) ON [PRIMARY]

GO

界面上是可以通过点击【共享】按钮看到该记录得共享记录的，实例如下：

共享给的权限很大，所有权限。若被共享用户本来不能删除这个记录，但是通过这个共享给了他删除权限，他是可以删除的，所以谨慎使用该功能，在项目上我们一般不启用【设置是否与原始负责人共享重新分派的记录】这个选项，还好这个默认就是关闭的。

如果我把这条记录删了，这些共享记录在POA表中不会立即自动删除，是由每天运行的服务(Operation Code为14，名称为 Deletion Service)来删除的，请参考  More juicy details on Dynamics CRM 2011 Asynchronous Service’s maintenance jobs 。

2.直接共享。这个容易理解，这样产生的POA记录的AccessRightsMask字段会有值(不会为0)，但是InheritedAccessRightsMask字段值为0。下面我做一个表来列出共享权限及其对应的AccessRightsMask值，但是我估计啊，这个值不一定对应对，别对这个表太当真。

3. 【行为类型】为【父】这种类型导致的共享，主要是因为【重定父级】这个选项的行为为【父】导致的。这里解释下，我这里有两个实体，一个是工单实体，一个是工单项目实体，假设我设置他们俩之间的【行为类型】为【父】。

现在有一条名称为【测试工单】的工单实体记录，记录的owner为我这个系统管理员。我用另外一个账号，新增一个工单项目记录和这个【测试工单】关联。保存后这样会产生一条POA记录，该POA记录的AccessRightsMask字段字段值为0，但是InheritedAccessRightsMask字段有值(不为0)。当然如果父记录的owner就是创建子记录的用户的话，这个POA记录不会产生。这种产生的共享记录点击【共享】按钮后在界面上看不到，但是在POA表中会存在记录。据我观察，如果重新分派后的owner和子记录的owner一样，那么POA记录表中子记录的AccessRightsMask字段字段值为0，且InheritedAccessRightsMask字段值为0。这种产生的共享记录点击【共享】按钮后在界面上看不到，但是在POA表中会存在记录。但是每天运行的系统作业(AsyncOperationType = 14)来定期运行来清理它(删除这条记录)。关于这个作业的临时修改运行时间请参考 Dynamics 365中的公告(Post)分析。所以要删除POA表记录，我认为一个方法就是，就是重新分派父记录，使其和子记录的owner一样，这样由【重定父级】产生的共享会被系统作业(AsyncOperationType = 14)运行后自动删除。当然，建立这种1:N父关系的那个字段的值如果清空，那么产生的POA记录也会被被系统作业(AsyncOperationType = 14)运行后自动删除。

如果要清除大量的由【父】这种行为类型的POA记录通过更改父记录Owner或者清空子记录和父记录做关联的字段值的话，耗时会比较就。这里介绍一种方法，可以执行类似如下的SQL，处理后这些记录会被系统作业(AsyncOperationType = 14)运行后自动删除。如果是Dynamics 365 Customer Engagement Online，可以开case来请求工程师帮忙处理。

update principalobjectaccess

set inheritedaccessrightsmask=0

where inheritedaccessrightsmask !=0 and accessrightsmask=0

特别提一下活动实体，默认情况下支持活动的实体和该所有的活动实体的【行为关系】为父，这样的父行为也会产生一条POA记录，POA记录的ObjectTypeCode为4200，AccessRightsMask字段字段值为0，但是InheritedAccessRightsMask字段有值(不为0)。该POA表对应的ObjectId是活动的Id,但是这里并不知道是哪种活动。当然啦，你可以拿这个ID用Web API查出来是那种活动，如下示例，这个返回的就是活动实体的逻辑名。

https://demo.luoyong.me/api/data/v9.0/activitypointers(94321554-6D44-E911-A81D-000D3A5129C5)?$select=activitytypecode

若是到数据库中查询，示例如下，返回的是实体的ObjectTypeCode:

select ActivityTypeCode from ActivityPointerBase where ActivityId='94321554-6D44-E911-A81D-000D3A5129C5'

4. 间接共享。就是关系行为中的【重定父级】和【共享】设置【全部级联】、【可用项的级联】、【用户负责项的级联】就很可能产生POA记录。比如【共享】设置为级联，共享了父记录，会产生POA记录自动共享子记录。如果【共享】设置为级联，强烈建议【取消共享】也设置级联，这样取消共享父记录的共享后，其子记录相关的共享记录会被系统作业(AsyncOperationType = 14)运行后自动删除。

总结一下，POA记录表中子记录的AccessRightsMask字段字段值为0的记录点击【共享】按钮看不到，一个用户/团队对一条记录最多产生一条POA记录。

你会发现有些共享是不需要的，特别是后两种自动产生的共享，如果用户本身就对这些被共享的记录有权限，就没有必要共享了，可以对POA表做一些清理，清理POA表可以参考：How to control PrincipalObjectAccess table growth in Microsoft Dynamics CRM 2011