CRM数据权限怎么设计：角色、数据范围与字段权限核对清单
CRM权限设计的难点，不是把“管理员、经理、销售”三个角色建出来，而是回答三个连续问题：这个人能进入哪些功能？进入后能看到哪些客户和业务记录？看到记录后，哪些敏感字段可以读、改、导出或转交？只做菜单权限，往往会出现“按钮看不见但接口仍可访问”；只做数据范围，又可能让普通销售看到手机号、成本价或回款账户等不该暴露的字段。
更稳妥的做法，是把权限拆成角色权限、数据范围、字段权限、操作权限、审计与例外五层。NIST SP 800-53 的 AC-6 控制强调最小权限；OWASP 授权指南进一步建议默认拒绝，并在每次请求上校验权限。对CRM来说，这意味着前端隐藏只是体验层，后端接口、批量导出、移动端和自动化任务都必须执行同一套授权判断。
一、先画业务对象，不要先建角色
先列出客户、联系人、线索、商机、报价、合同、回款、发票、跟进记录、售后工单等对象，再标出每个对象的负责人、所属部门、协作团队和敏感字段。权限的对象不是抽象的“CRM”，而是这些有归属、有状态、有上下游关系的数据。
建议先做一张“对象—动作—范围”矩阵。例如销售可以创建客户、读取本人客户、编辑本人未锁定客户；销售经理可读取本部门客户、审批本部门报价；财务可读取合同与回款，但不必看到全部销售跟进内容；客服可读服务所需的联系人信息，却不能修改客户归属。企业也可先查看客户云的客户与销售流程，再按真实业务链路拆对象。
二、角色权限：定义“能做什么”
角色适合表达稳定的岗位职责，而不是为每位员工单独复制一套权限。常见基础角色包括一线销售、销售经理、渠道经理、客服、财务、运营和系统管理员。每个角色至少要逐对象核对创建、读取、编辑、删除、分配、共享、审批、导出、打印与批量操作。
- 避免万能角色：“销售经理”不应自动等于全公司数据可见，更不应附带系统配置权限。
- 控制角色叠加：多个角色通常会产生权限并集；给用户增加第二个角色前，应重新计算最终有效权限。
- 分离业务与管理权限：配置字段、修改流程、管理账号、查看业务数据应分开授权。
- 高风险动作单列：删除、批量导出、客户转移、合同作废和权限分配应独立控制并记录日志。
Microsoft Dataverse 的安全模型同样把安全角色与访问级别结合使用，并提醒多个角色的效果会累加。这个思路适合用来检查CRM里“角色名称合理、实际权限却过宽”的问题。
三、数据范围：定义“能看哪些记录”
数据范围通常至少包括本人、本人与下属、本部门、本部门及下级部门、协作团队、指定区域或产品线、全部数据。不要只根据组织树决定范围，还要考虑客户归属、共享关系、项目成员和临时协作。
一条客户记录可以采用“主负责人 + 协作人 + 所属部门 + 授权团队”的方式计算访问范围。矩阵组织中，同一员工可能同时服务华东区域和某产品线，此时固定部门继承往往不够，需要把区域、产品、客户等级或项目成员等属性纳入判断。访问规则应写出优先级：显式拒绝是否覆盖共享？离职后协作权限何时回收？客户转移后原负责人还能否查看历史跟进？
数据范围还要覆盖关联对象。销售能看客户，不代表自动能看该客户全部合同、回款和售后记录；反过来，财务能看回款，也不应因为关联查询而获得整张客户画像。建议逐条测试主对象、关联列表、搜索结果、看板统计和导出文件，避免“详情页拦住了，报表却泄露”。
四、字段权限：定义“看到什么细节”
字段权限至少分为可见、脱敏可见、可编辑、只读和不可见。手机号、身份证号、家庭住址、个人微信、成本价、折扣底价、银行账户、回款信息与内部风险备注，应根据岗位和业务必要性单独控制。
脱敏不能只改页面显示。搜索、联想框、导出、打印、消息通知、API、移动端、自动化变量和日志都可能把完整字段带出去。验收时要从不同入口验证同一字段：列表是否脱敏、详情是否脱敏、导出是否脱敏、接口是否返回、审批通知是否带出。对需要临时查看完整值的场景，可采用申请审批、限时授权和查看留痕，而不是长期开放。
五、可直接执行的权限核对清单
- 账户与角色：离职账户是否停用？共享账号是否清理？管理员是否仅限必要人员？角色叠加后是否越权？
- 记录范围：本人、部门、下属、团队、区域和产品线规则是否写清？转移、共享、公海领取后范围是否正确？
- 字段保护：手机号、价格、合同、回款和风险备注是否分级？PC、移动端、API、导出和通知结果是否一致？
- 高风险动作：批量导出、删除、转交、合并、作废、审批与权限分配是否单独授权？
- 自动化身份：定时任务、集成账号和机器人是否使用最小范围的服务账号？密钥轮换与停用机制是否明确？
- 审计证据：谁在何时查看、修改、导出、转移了哪条数据，是否能查询并设置保留期？
- 异常与拒绝：无权限时是否默认拒绝？直接输入记录ID、调用旧接口或切换终端是否仍被拦截？
- 变更流程：岗位调动、跨部门协作、离职交接和临时授权是否有申请、审批、到期回收与复核？
六、上线前怎么验收
至少准备五类测试账号：普通销售、跨部门协作销售、销售经理、财务或客服、系统管理员。每类账号都做正向与反向测试：该看的能看、该改的能改，不该看的通过列表、搜索、URL、接口、报表和导出都拿不到。不要只让管理员演示一遍配置页面。
权限变更也要测试时效：新增角色后何时生效，移除角色后缓存多久失效，员工离职后会话是否立即退出，临时授权是否按时回收。若CRM还要接入审批、报表或自定义表单，可参考低代码办公与审批能力，把权限验收纳入流程上线清单；涉及旧系统替换时，可配合CRM数据迁移8步清单同步检查负责人和共享关系是否迁移完整。
七、最终交付物应包含什么
一套可维护的CRM数据权限，不应只剩几张配置截图。交付物至少包括角色权限矩阵、数据范围规则、敏感字段分级表、例外授权流程、测试用例、审计日志说明和权限变更记录。每季度或组织调整后复核一次高权限账号、跨部门共享、长期未使用角色和服务账号。
如果正在选型，建议把上述清单直接写进演示脚本和验收条款：让供应商现场用不同账号验证同一条客户、同一字段和同一导出任务，而不是只回答“支持权限”。不同部署与服务范围可在CRM价格与交付方案中继续核对，再结合企业组织结构形成最小可用权限基线。