我是微软Dynamics 365 & Power Platform方面的工程师/顾问罗勇，也是2015年7月到2018年6月连续三年Dynamics CRM/Business Solutions方面的微软最有价值专家(Microsoft MVP)，这是我的第485篇原创文章，写于2022年9月29日。
我先准备了如下测试数据：
一个角色，对涉及到的三个实体的所有权限都是个人级别的。
两个用户(分别为Test User 1和Test User 2)用来测试，都授予了前面所说的这个角色，并且验证了两个账号创建的数据互相不可见。
三个实体，分别是Test Entity, Test Sub Entity 和 Test L3 Entity，他们都是后面的实体都有一个字段Lookup到前面的实体，并且用2个不同的账号为这3个实体分别造了4条数据。
我们知道新建Lookup字段，建立的这个 1:N 关系的行为是 Referential 。
我将Name为 test user 1 这条Test Entity记录共享读权限给 test user 2，
然后我登录Test User 2，可以看到这条共享给她的记录，点击命令栏的 Check Access 按钮，弹出框内容如下，清楚的告诉我对这这条记录只有读权限，是通过共享给我来授予的。因为关系行为是Referential，正如我们预料的，看不到这条记录下面的Test Sub Entity和Test L3 Entity。
然后我更改下Tes Entity 和Test Sub Entity关系行为为Parental，保存并发布这两个相关实体。
然后登录Test User 2去看，没有看到Name为 test user 1的Test Entity的子记录，这么看来在关系更改前的共享是不会级联的。
那么我将Name为 test user 1 -1 这条Test Entity记录共享给Test User 2读权限，符合预期，可以看到这条记录的子记录，如下。
打开这条子记录，点击 Check Access按钮，告诉我是因为我对相关记录有访问权限所有也共享给我了。
我继续做个验证，如果我用Test User 1对Name为 test user 1 -1 这条Test Entity记录增加一条子记录呢，那么这条共享发生之后的记录是否会也自动贡献给Test User 2呢？
看到结果如下，可以知道是会自动共享给Test User 2的,我点开这条新记录的后检查Check Access，显示的内容和前面一致，也是因为我对相关记录有访问权限而共享给我的。
我还继续验证下，第三层是否会自动共享，也就是说，我将Test Sub Entity和Test L3 Entity的1:N关系也改成Parental后发布，然后共享Name为 test user 1 -2 的Test Entity记录给Test User 2。
登录Test User 2是可以看到Name为 test user 1 -2 的Test Entity记录下第二层实体Test L3 Entity记录的，如下图。
如果对这个 Test L3 Entity记录点击Check Access按钮的话，也是和之前一样的提示，是因为我对相关记录有访问权限而共享给我的，这个相关记录指的是第一层的记录，也就是Name为 test user 1 -2 的Test Entity记录。
我还验证下 RecordInfo function in Power Apps 函数对这个权限的判断是否准确，使用的表达式是 Text(RecordInfo(LookUp('Test Entities',Name = "test user 1 -3"),RecordInfo.EditPermission)) 。我将Name为 test user 1 -3 的Test Entity记录共享Write权限给了Test User 2，在Model-Driven App界面我确认了Test User 2对这个记录的权限如下，有Write权限，是通过共享拿到的。
正如前面验证的，那么Test L3 Entity的相关记录也会共享Write权限给Test User 2，在Model-Driven App界面验证的确如此。
经过验证，RecordInfo函数获取到的对记录的权限是正确的，返回了Test User 2对这两条因为共享而有Write权限的记录也是有Write权限的。那它是怎么获取的呢？我抓取网络包看了下，应该是发起了一个类似 systemusers(50b3dfb1-d23f-ed11-bba2-000d3a856af9)/Microsoft.Dynamics.CRM.RetrievePrincipalAccess(Target=@tid)?@tid={'@odata.id':'ly_testentities(5ab411ed-d53f-ed11-bba2-000d3a856af9)'} 这样的请求，返回内容是 {"@odata.context":"https://orgb3d503cc.crm5.dynamics.com/api/data/v9.0/$metadata#Microsoft.Dynamics.CRM.RetrievePrincipalAccessResponse","AccessRights":"ReadAccess, WriteAccess"} 。
最后总结下：
- 级联设置好后，新增子记录，依然会自动按照级联关系进行设置相关权限。
- 至少三层，父-子-孙是支持级联设置的，更多层本文未验证。
- RecordInfo函数返回的结果是准确的，哪怕这个权限是因为共享，乃至级联导致的共享都获取到没问题。