访问权限与角色
访问权限决定谁能在门户中看到什么、能做什么。对所有者和管理员而言，这不是一堆勾选项，而是一套责任模型：员工处理自己的任务和客户，负责人查看本部门，而他人的数据在没有被有意授权之前始终保持封闭。
本页说明访问权限模型。具体设置位于门户管理板块——参见 门户管理。
角色
概念性说明，不是 UI 截图，也不证明门户数据。
访问权限的基础是三种角色：
- 管理员——配置门户、权限与策略；查看并管理较大范围的内容。
- 负责人——负责自己的部门或方向；查看本团队的工作。
- 员工——处理自己的任务、客户和资料。
角色设定了基础访问级别，而具体权限则由按范围和模块划分的策略进一步细化。
访问范围
概念性说明，不是 UI 截图，也不证明门户数据。
访问权限不是「一次性开放全部」，而是按范围授予。范围就是权限生效的边界：整个公司、某个部门、某条管道、某个阶段、某个项目或某位具体用户。
因此同一名员工可以在自己的项目中拥有较广的访问权限，而在他人的项目中完全没有权限。这样就能只开放工作真正需要的部分，而不暴露多余内容。
权限：读取、修改、管理
概念性说明，不是 UI 截图，也不证明门户数据。
在每个范围内，权限由多个级别组成：
- 读取——查看对象及其内容；
- 创建——建立新对象；
- 修改——编辑已有对象；
- 管理——配置该范围内的访问权限与规则。
请有意识地区分这些级别：能看到不等于能修改，能工作也不等于能把权限分给他人。
策略控制的内容
概念性说明，不是 UI 截图，也不证明门户数据。
模块选择器除了任务和 CRM，还包括工作流、聊天、项目、用户、公司、时间、自动化、AI 助手、运营和文档。每条策略选择范围和角色。部门值可以显式设置、从父部门继承或使用模块 回退；应用到子部门会向下传播。显式规则中，创建和管理与读取、修改相互独立。
任务策略还控制向下、向上及部门间分配，可单独限制方向、层级、目标角色和用户允许/拒绝列表。 在 CRM 中，机会可见性与漏斗/阶段范围属于同一策略；不需要这些范围时请留空。
对于带有自动化 schema 的模块，CRUD 权限下方还会显示 capability 控件。每项 capability 可设为允许、拒绝或继承，它与读取、修改和管理权限分开。批量操作可以一次 设置全部 capability。AI 助手提供可选的回复、回复加操作以及恢复继承预设；这些操作只 设置策略，不会运行自动化或修改数据。
如果部门策略继承父部门或模块回退值，选择显式来源前 capability 控件会被禁用。模块没有 加载 schema 时会显示相应状态，不应手动输入技术 capability 名称。
对于 Operations，列表首先显示为 Operations 模块登记的权限及其本地化易读名称。 已保存在策略中的权限即使不属于该模块的常规列表也会继续显示，以便明确检查和修改。 列表变短并不代表访问已被移除：保存前请检查每项可见权限的允许、拒绝或 继承状态，不要手动输入技术名称。
检查和撤销变更
概念性说明，不是 UI 截图，也不证明门户数据。
删除规则或应用以前的修订版本都需要填写原因。历史中的长摘要可以展开。CRM 管理员可以运行 Explain 或 Simulate 检查访问结果；这些检查不会修改策略。
默认访问模式
概念性说明，不是 UI 截图，也不证明门户数据。
各模块会设定默认访问模式——即在没有明确规则时会发生什么：
- 严格——默认访问封闭；只有策略明确允许的内容才开放。适合敏感数据和大型公司。
- 开放——默认开放读取和工作权限，而策略用于限制个别范围。适合信任度高的小团队。
对于包含客户和财务数据的模块，从严格模式起步更安全，再按需逐步开放访问。
变更历史与理由
概念性说明，不是 UI 截图，也不证明门户数据。
修改访问权限是一项管理决策，而非不留痕迹的改动。因此在变更策略时，系统会要求填写变更理由，并保存修改历史：谁在何时、出于什么原因更改了访问权限，都一目了然。
这对于监督和事件复盘很重要：如果有人看到了不该看的内容，或者相反地失去了访问权限，通过历史就能弄清是哪次变更导致的。
日志使用易懂的字段名称，不会显示内部字段名称或技术细节。无法映射名称的字段
会折叠为 +N 摘要，不会泄露技术数据。保存规则后，登记表会自动切换到该规则
所属的模块，使新行保持可见；请在那里核对，再重新读取最终权限。
良好实践
概念性说明，不是 UI 截图，也不证明门户数据。
- 按范围和角色授予访问权限，而不是「以防万一」开放整个公司。
- 区分查看权与修改权；管理访问权限的权力只交给少数人。
- 对于包含客户和财务数据的模块，保持默认严格模式。
- 变更策略时写明清晰的理由——它会留在历史中。
- 定期复查访问权限：当角色和项目变化时，移除多余的权限。
常见错误
概念性说明，不是 UI 截图，也不证明门户数据。
- 授予覆盖整个公司的广泛访问权限，而不是按范围授权。
- 把查看权与修改权混淆——员工不小心改动了他人的数据。
- 在包含敏感数据的模块中保留默认开放模式。
- 变更策略却不写理由——事后无法弄清访问权限为何变成这样。
- 角色更换或项目结束后不复查访问权限。
相关板块
概念性说明，不是 UI 截图，也不证明门户数据。