权限、角色与看不见的数据

适用场景

看不见 Tab、列表少行、字段灰掉、保存 forbidden、能看不能送审。你要用业务语言向管理员描述现象，并自查是否与 Sharing 或状态有关。

谁能做什么：四层叠加

最终能否看见或修改一条记录，通常由下述层次 共同 决定（自上而下都满足才可能成功）：

缺一层都会表现为：无 Tab、列表空、详情只读、动作为灰或 forbidden。Vault Owner / 系统管理员 可绕过部分检查用于排障，日常业务账号不应依赖。

PermissionSet（用户视角）

管理员把 PermissionSet 挂到你的 Security Profile。你不用编辑 PermissionSet，但要能把现象映射成权限类：

同一 Vault 内可有 多 PermissionSet 叠加（按 Profile 设计）；「QA」「调查员」「文控」等命名因客户而异。

记录上的生命周期角色

许多流程在记录上维护 Owner、Editor、Viewer 等（名称依生命周期定义）：

角色来源：创建规则、工作流步、手工 Sharing、或应用自动写入。 任务参与人 与 生命周期角色 可联动但不等价——被指派审批不等于你是 Owner。

Sharing 操作（记录级）

1. 打开记录 Sharing（或团队成员）区域。
2. 添加用户/组并选角色（若你有权分享）。
3. Sharing 解决「这条记录可见/可协作」；不能代替 PermissionSet 里有没有对象 read。

无 Sharing 时，匹配规则或父记录继承可能仍给你访问权（依库配置）。

字段级与布局层

即使对象有 edit，仍可能：

• 字段级权限 禁止改某一列；
• 布局规则 在某状态隐藏或只读字段；
• 入口条件 要求先填子对象才能解锁字段。

现象是「同一记录同事能改、我不能」：先比 Profile，再比 Sharing/角色，最后比状态。

应用侧效应与 On Behalf Of

应用 代建子记录（如 QMS Promote 建投诉）用系统写库，审计记点击用户为发起人（On Behalf Of）。这不自动授予你对子对象全部 edit 权限；子记录仍按 PermissionSet 与 Sharing 授权。

代建 不等于 你可以手工在 UI 里 create 该对象——若 create 被收窄，手工仍会 forbidden。

自查清单（找管理员前）

1. 你与他人 Security Profile 是否相同？
2. 这条记录 Sharing 是否包含你？状态是否不同？
3. 当前 生命周期状态 是否禁止该动作（尤其批准中）？
4. 是否应在 我的任务 完成而非详情里点批准？
5. 子对象 forbidden 是否缺 子对象 create/edit？

管理员侧入口：Admin / Business Admin（Users & Groups、Permission Sets、Objects）。业务帮助不展开 MDL 装载。

常见问题

下一步

• 列表与详情交互 → 对象、列表与记录详情
• 批准中为何不能状态下拉批 → 生命周期与用户动作