权限分配

这是管理员每周都会遇到的访问问题的任务指南。模型总览解释各层如何工作；本页告诉你该点哪里。

**90% 的日常管理就是把人分配到岗位。**岗位、其背后的权限集以及安全基线都随平台和你安装的应用一起交付。你几乎从不需要从零构建能力——也不应该那么做。

用户的有效访问是叠加式的：

effective access = union of permission sets reached through positions
                 + direct grants
                 + the built-in member_default baseline

限制通过不授予来实现——没有需要维护的减法规则。

新员工入职

四个有序步骤，每一步依赖上一步：

分配岗位

一次分配就是一行记录：User Position（用户岗位，sys_user_position）= 用户 + 岗位 + 可选的任职业务单元。这个锚点决定岗位的深度授权在哪里生效——"东区销售经理"看到的是东区的记录，而不是整个公司的。

在 Setup → Access Control → Positions（岗位）中打开某个岗位，从其相关列表添加分配（或直接创建 User Position 行）。这些写入受治理约束：租户级管理员可以通过；委派管理员只能在自己的子树内分配白名单中的权限集——自我提权在结构上就会被拒绝（见委派管理）。

两个相邻的界面补全全貌：

• 直接授予——在权限集的记录页（Setup → Access Control → Permission Sets）上，Assigned Users（已分配用户）面板可添加不经岗位的按用户授予。经岗位持有的行也会显示，但要在岗位上移除，不能在这里移除。
• 业务单元成员资格——来自第 2 步；独立于分配锚点。

变更某人的角色

当某人调换部门或职能时：

1. 把其 Business Unit Member（业务单元成员）行更新为新单元。
2. 重新锚定其 User Position 行——移除或编辑锚定到旧单元的分配，为新单元添加分配。
3. 移除属于旧角色的所有直接授予。
4. 验证（见下文）。

分配可以携带 valid_from / valid_until 时间窗口——过期的授予立即停止解析，这是处理计划内交接或临时代理角色的干净方式。参见权限集。

验证某人能看到什么

两个内置的验证工具：

• **模拟。**用户列表 → 行菜单 → Impersonate User（模拟用户）。你会获得该用户的会话——打开他们会打开的应用，确认他们能看到该看的（且看不到不该看的）。模拟仅用于正当的支持与验证；会话会被记录。
• **解释。**Studio 的 Access（访问）板块 → Explain access（解释访问）：选定用户、对象和操作，引擎返回判定结果以及每个求值层——哪个权限集授予了权限、经由哪个岗位持有、哪条共享规则放宽了范围、哪条策略收窄了范围。

同样的报告也可通过 REST 获取：

# GET，查询字符串形式
curl -H "Authorization: Bearer $TOKEN" \
  "$BASE/api/v1/security/explain?object=crm_lead&operation=read&userId=usr_123"

# POST，请求体形式
curl -X POST -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  -d '{"object":"crm_lead","operation":"read","userId":"usr_123"}' \
  "$BASE/api/v1/security/explain"

operation 取 read | create | update | delete | transfer | restore | purge 之一（默认为 read）；省略 userId 则解释你自己。解释自己始终被允许；解释其他用户需要 manage_users 能力，或覆盖该用户的委派管理作用域。

当权限解析结果不对时，先解释胜过瞎猜乱试：报告会点名需要修正的确切权限集和层。参见诊断与审计一节。

办理离职

1. Ban User（封禁用户）——立即阻止登录。这是唯一紧急的一步。
2. 之后从容移除其岗位分配和直接授予。
3. 移除或改挂其业务单元成员行。
4. 撤销绑定到该用户的所有 API Key——Key 以该用户身份行事，只要底层授予还在，它就还能用。

当自带的岗位不合用时

权限在 Studio 中设计，在 Setup 中分配。如果没有自带岗位能满足需求，优先选择能解决问题的最小改动，顺序如下：

1. 把现有权限集绑定到岗位。
2. 克隆一个自带权限集并调整。
3. 在 Studio 的权限集矩阵编辑器中编写新权限集——一张结构化的电子表格，覆盖对象增删改查、字段级安全和能力；你永远不需要手写 JSON。

编辑随应用交付的权限集会创建一个环境覆盖层（environment overlay）——你的修改优先生效、在升级后保留，并可重置回厂商基线。牢记叠加模型：编写内聚的能力包，绝不要写"减法权限集"。参见权限集。

把需求转化为改动时，选择匹配的层：

快捷路径

各项在哪里

下一步