咱们先从报错信息入手："The requested operation cannot be completed due to security restrictions. Please contact your system administrator. (Document type: Employee, Operation: read) - (Records: [15], User: 13)" 这说明员工B（用户ID13）的账号连自己的Employee记录（ID15）的读取权限都没有，核心问题肯定出在权限配置或者数据关联上，下面是具体的排查步骤：

1. 先查角色权限基础设置 #

• 找到员工B所属的用户角色（比如「普通员工」这类角色），去权限配置里看这个角色对Employee文档类型的权限：有没有勾选read权限？
• 很多系统会细分权限范围：「所有记录」「仅自身记录」「所属公司记录」，要确保这个角色至少拥有「仅自身记录」的read权限——毕竟连自己的记录都看不了，大概率是这个范围没配置对。

2. 验证员工记录与用户账号的关联 #

• 确认Employee记录ID15（也就是员工B的记录）里的用户关联字段（比如user_id）是不是确实指向用户ID13；同时检查company_id是不是正确关联到companyB。
• 系统的权限规则很多时候依赖这些关联字段，如果关联错了，权限判定就会认为这条记录不属于员工B，自然不让访问。

3. 检查多公司隔离的权限规则 #

• 因为你设置了companyA和companyB两个独立公司，系统大概率开启了多租户/公司级数据隔离。这时候要确认：
  • companyB对应的权限规则里，是否允许本公司员工访问自己的Employee记录；
  • 有没有全局的权限规则搞“一刀切”——比如管理员误设置了「所有非管理员用户禁止访问Employee记录」，这会直接覆盖角色权限。

4. 深挖具体的权限规则优先级 #

• 直接去系统的权限规则模块，找针对Employee文档的read权限规则：
  • 有没有专门针对用户ID13的拒绝规则？
  • 规则的优先级是不是搞反了？比如拒绝规则的优先级比允许规则高，哪怕角色有允许权限也会被拒绝；
  • 规则的条件有没有写错？比如把companyA的规则套用到了companyB上。

5. 临时测试定位问题 #

• 可以临时给员工B的账号加一个拥有Employee全量read权限的角色（比如临时管理员），如果这时候能正常访问，就百分百确定是角色权限配置的问题，再慢慢调整回合适的权限范围就行。

内容的提问来源于stack exchange，提问作者Ing