美洽账号权限继承规则

美洽的账号权限继承遵循“父级角色设定向子账号/部门传播、但关键凭证与第三方授权不随意转移”的基本思路：角色与部门层级会把权限模板下发给成员，删除或转移用户会触发会话与任务重分配，而账号所有权、API 密钥、微信/支付宝等渠道授权需要单独移交或由管理员在后台完成。

先把总体概念说清楚（像讲故事一样）

想像一家公司把钥匙和使用说明分发给员工。美洽里有“谁能看、谁能操作、谁能接入外部渠道”这三类钥匙：角色权限、会话/数据访问权、以及第三方/平台凭证。权限继承，其实就是父级把“使用说明”和部分“钥匙”发给子级，但有些真正的主钥匙——比如账号所有权或对外授权——不会自动给别人，必须按流程单独交接。

基本角色与层级（先搞清谁是谁）

• 账号所有者（Owner）：原则上拥有最高权限，能看到账单、付款、对外授权和账号设置。
• 管理员（Admin / Manager）：管理团队、设置权限模板、创建/删除部门与成员、分配分工。
• 坐席/客服（Agent）：日常接待客户、处理会话和工单，权限通常受分配角色限制。
• 自定义角色：企业可根据需要自定义权限集合，然后把这个模板赋给成员或部门。

权限继承的几个核心原则（一句话说清）

• 模板驱动继承：父级（账号/部门/上级角色）定义的权限模板会下发给子级成员，成员默认继承该模板权限。
• 成员可被覆盖：管理员可以对单个成员做权限的加减，覆盖继承结果。
• 敏感凭证不继承：API 密钥、对接的第三方平台授权（如微信公众号、支付渠道）以及账单信息不会自动随角色继承，需管理员或所有者单独操作。
• 会话与数据访问按分配决定：会话历史通常保留，但新旧会话的处理权、自动分配规则会随组/坐席变动而调整。

举个生活化的例子

就像你在公司建了一个“售后部”模板，里面写好了“能看订单、能转接会话、不能看财务”。新进人自动穿这套“制服”。但公司的对外微信号的钥匙还是放在老板抽屉里，别人拿不走，必须老板亲自交接或在后台授权。

细项清单：到底哪些会被继承，哪些不会？

发生这些操作时，继承会怎样变化？（常见情景）

1. 新增成员或加入部门

规则通常是：成员自动继承该部门或分组设定的权限模板。管理员可以在成员创建后立刻调整权限（例如：禁止某人导出数据）。

2. 升级或降级角色

当你把坐席升为管理员，他会立刻获得管理员模板的权限；反过来降级则会丧失部分权限。变更后，有时需要刷新或重新登录才能看到权限差异。

3. 删除成员或离职交接

• 会话：系统会提示转交未完成会话，需要重新分配给其他坐席或部门。
• 历史：聊天记录通常保留在系统，供有权限的人查询。
• 凭证：如果该成员持有对外授权，管理员需在后台撤销并由其他人重新授权。

4. 转移账号所有权

账号所有权的移交往往不是“继承”，而是“转让”。这一步可能需要：原所有者在后台提交变更或联系美洽客服完成。转让后，新所有者获得账单、渠道授权和最高权限。

权限继承管理的最佳实践（做得清楚更省心）

• 用模板管理权限：把常见岗位的权限做成模板，新增人员直接套用，便于审计。
• 最小权限原则：默认给最低权限，工作需要时再开通，减少泄露风险。
• 敏感凭证集中管理：API 密钥、渠道授权、财务信息只保存在少量可信管理员手中，禁止随意分发。
• 设置离职流程：包括会话转交、凭证回收、账号冻结等步骤，最好形成 Check-list。
• 定期审计：每季度核对谁有啥权限，删除长期不需要的访问。

操作细节提示（别忘了这些容易忽略的小地方）

• 有些权限变更需要用户重新登录或等待短暂生效期。
• 自动化规则（如关键词转接）会对继承的成员生效，但触发条件仍由管理员维护。
• 当部门策略与单个成员权限冲突时，通常以“成员的显性设置”为准（先定义后覆盖的规则），不过不同系统实现略有差异，遇到冲突别慌，先在后台查看实际生效权限。
• 若使用 SSO（单点登录）或企业微信/钉钉对接，角色同步可能会遵循外部目录策略，权限继承会受外部目录影响。

常见问题速答（像跟同事聊天那样简短）

• 问：删除一个坐席，会丢失聊天记录吗？ 答：一般不会，聊天记录保存在系统，但未完成的会话需要转交。
• 问：能把 API 密钥直接转给新管理员吗？ 答：原则上不建议直接转发，应该在后台由账号所有者或管理员重新生成/绑定。
• 问：部门权限改了，成员会马上生效吗？ 答：通常会很快生效，个别功能可能需用户重新登录。

如果你要实际操作，按这一步走（实用清单）

• 确认当前账号所有者与管理员名单（谁能动账单与渠道）。
• 在后台查看或导出权限模板与成员清单，标识敏感凭证持有人。
• 对需要继承的权限建立或更新模板，分配给部门/成员。
• 对敏感凭证做集中交接：在渠道侧（公众号/WhatsApp/支付）完成移交或重新授权。
• 执行离职或转交流程：转接会话、撤销个人凭证、冻结或删除账号。
• 完成后做一次权限审计，确保没有过期或多余的访问存在。

有点技术味的补充（开发者/运维可能会想知道）

API 层面常见做法是把访问控制做成基于角色的访问控制（RBAC）。角色到用户的关系存在数据库表，变更时后台会写审计日志。重要的是，API Key 通常绑定到账号或应用，不随用户角色变更；如果需要程序化转移，往往要调用专门的迁移接口或让新所有者在控制台生成新的密钥，然后使旧密钥失效。

说到这儿，可能你已经在想着具体要怎么做了——别急，按清单一步步来，先把“谁能做什么”弄清，再处理凭证和会话接续，问题会小很多。要是遇到后台看不到的异常情况，找客服或查看产品官方文档里的“账号迁移/角色管理”章节会更稳妥。