CRM 权限系统怎么设计？角色、数据范围与字段权限实践

为什么权限设计是 CRM 的核心

企业采购或自建 CRM 系统，最常踩的坑不是功能不够，而是权限失控。要么销售可以随意查看全公司客户，导致客户资源被带走；要么审批流程过于严格，业务员连修改一条跟进记录都要等经理审批，效率骤降。

权限设计本质上是在安全与效率之间找平衡点。一套好的权限系统，应当让每个角色只看到自己该看的数据，只操作自己该操作的功能，同时保证日常协作不被打断。

本文从 RBAC 模型出发，结合实际项目经验，讲解角色、数据范围、字段权限、审批流程和操作日志这几个关键维度。内容不涉及特定产品，而是通用的设计思路，适合正在规划或重构 CRM 权限的团队参考。

RBAC 模型：权限控制的基础框架

RBAC（Role-Based Access Control）是目前最成熟的权限模型，核心思路是把权限赋予角色，再把角色赋予用户。用户不直接关联权限，而是通过角色间接获得。

三个核心元素

• **用户（User）**：系统操作者，例如销售员、销售经理、客服。
• **角色（Role）**：权限集合的载体，例如“销售专员”“销售主管”“系统管理员”。
• **权限（Permission）**：对某个资源的具体操作，例如“创建客户”“编辑商机”“删除合同”。

一个用户可以拥有多个角色，一个角色也可以被多个用户共享。这种设计让权限管理变得灵活且可维护。

角色与权限的映射方式

在实际项目中，权限通常被细分为“功能权限”和“数据权限”。功能权限控制能否执行某个操作（比如“导出客户列表”），数据权限控制能操作哪些数据（比如“只看本部门的客户”）。

功能权限的分配相对简单，常见做法是在角色配置页列出所有功能模块，勾选即可。数据权限则需要更精细的规则，后面会详细讲。

常见角色设计示例

以一家中型销售型公司为例，典型的角色包括：

• **销售专员**：创建和编辑自己的客户、跟进记录、商机。不能查看其他销售的数据。
• **销售主管**：查看本团队所有客户的进展，可以分配客户给组员，能审批组员的折扣申请。
• **销售总监**：查看所有团队的数据，能跨部门调配客户资源，可配置公共客户池规则。
• **系统管理员**：拥有全部权限，负责角色配置、字段设置、系统维护。

角色数量不宜过多，一般不超过 10 个，否则管理成本会急剧上升。如果业务复杂，可以通过“角色继承”或“角色组”来减少重复配置。

部门数据范围：控制可见性的第一道门

部门数据范围决定了用户能看到哪些记录。这是 CRM 权限中最容易出问题的环节。

数据范围的常见层级

从严格到宽松，数据范围通常分为以下几级：

1. **仅本人**：只能看到自己创建或分配给自己的记录。适用于销售专员。
2. **本部门**：能看到所属部门内所有成员的记录。适用于部门主管。
3. **本部门及下属部门**：适用于有组织层级的公司，比如销售一部经理能看到销售一部和二部的数据。
4. **全部数据**：适用于总监及以上角色。

设计时需要注意：数据范围是叠加的。如果用户拥有多个角色，系统应该取权限最大的范围。例如用户同时是“销售专员”（仅本人）和“数据查看员”（全部数据），那么他应该能查看全部数据。

实现部门树与数据隔离

部门结构通常用树形表存储，每个部门有一个 parent_id 字段。查询数据范围时，需要递归获取所有子部门 ID。

举例：用户所属部门 ID 为 3，数据范围是“本部门及下属部门”，那么 SQL 查询条件大致为：

```
WHERE department_id IN (SELECT id FROM departments WHERE path LIKE '/1/2/3/%' OR id = 3)
```

这里 path 字段存储了部门路径，如 `/1/2/3/`，可以快速匹配所有子部门，避免递归查询性能问题。

常见陷阱

• **部门归属不明确**：有些员工属于多个部门（如同时负责销售和售后），系统需要支持“主部门”和“兼职部门”区分，数据范围默认按主部门计算。
• **部门调整后历史数据归属**：员工调部门后，之前创建的客户是否还属于他？常见做法是保留历史记录归属，新数据按新部门计算。也可以提供手动批量转移功能。

记录归属与共享：谁可以操作哪些数据

数据范围控制的是“可见”，记录归属控制的是“可操作”。一条客户记录通常有“创建人”“负责人”“共享人”等字段。

负责人机制

每条记录有一个明确的负责人（owner），这是权限控制的最小单元。负责人拥有该记录的完整操作权限（编辑、删除、转移等）。如果记录没有负责人（比如公共客户池），则所有有权限的人都可以认领。

负责人的分配方式包括：

• **手动分配**：管理员或主管直接指派。
• **自动分配**：根据规则（如地域、行业、客户来源）自动分配给空闲销售。
• **抢单模式**：销售从公共池自行认领，适合电销场景。

共享机制

实际业务中，一条记录可能需要多人协作。比如一个大客户由销售 A 负责，但需要售前工程师 B 协助演示。此时就需要共享机制。

共享可以按以下维度设置：

• **共享给特定用户**：直接添加用户 ID。
• **共享给角色**：比如共享给“售前工程师”角色下的所有人。
• **共享给部门**：部门内所有成员都能看到该记录。

共享权限可以细分为“只读”“可编辑”“可转移”。设计时要注意：共享权限不应超过负责人权限。例如负责人设置了只读共享，被共享者就无法编辑。

记录转移与继承

销售离职时，需要批量转移客户。系统应支持：

• **手动转移**：管理员选择源用户和目标用户，一键转移。
• **自动转移**：设置规则，比如用户离职后 30 天未登录，自动将记录转移给主管。

转移时，操作日志必须记录转移时间、操作人、原负责人和新负责人。

字段权限：精细到每个输入框

字段权限是进阶需求，但很多 CRM 项目在初期就会遇到。比如：销售可以填写“预计成交金额”，但只有经理才能看到“成本价”字段。

字段权限的三个维度

1. **可见性**：用户能否看到这个字段。不可见的字段在表单和详情页中完全不显示。
2. **可编辑性**：用户能否修改这个字段的值。常见场景：销售可以编辑“客户名称”，但不能编辑“客户等级”（由经理设定）。
3. **必填性**：字段是否必须填写。不同角色对同一字段的必填要求可能不同。例如销售创建客户时“手机号”必填，客服创建时“邮箱”必填。

实现方式

字段权限通常基于角色配置。在系统设置中，每个字段对应一个权限矩阵：

| 字段名 | 销售专员 | 销售主管 | 系统管理员 |
|--------|----------|----------|------------|
| 客户名称 | 可见、可编辑 | 可见、可编辑 | 可见、可编辑 |
| 成本价 | 不可见 | 可见、只读 | 可见、可编辑 |
| 客户等级 | 可见、只读 | 可见、可编辑 | 可见、可编辑 |

配置时需要注意：字段权限的优先级高于角色权限。比如销售主管的数据范围是“本部门”，但如果某个字段被设为“不可见”，即使数据范围允许，他也看不到该字段。

字段权限的常见陷阱

• **表单验证冲突**：如果字段对 A 角色必填，对 B 角色非必填，后端验证逻辑需要根据当前用户角色动态判断。很多项目在这里出 bug，导致保存失败或数据缺失。
• **批量操作时的权限检查**：批量修改客户时，系统需要逐一检查每个字段的编辑权限。如果某个字段用户无权修改，要么跳过该字段，要么提示用户。
• **导出时的字段过滤**：导出 Excel 时，用户只能导出自己有权限看到的字段。否则会出现“明明看不到成本价，导出时却出现了”的尴尬。

审批流程：在权限不足时提供临时通道

权限再完善，也总有例外。比如销售需要给客户一个超出标准折扣的价格，或者客服需要删除一条误创建的错误记录。此时审批流程就派上用场。

审批与权限的关系

审批不是替代权限，而是权限的补充。当用户试图执行一个他当前角色不允许的操作时，系统可以触发审批流程。

常见场景：

• **折扣审批**：销售提交高于权限的折扣申请，经理审批。
• **删除审批**：销售提交删除客户申请，主管审批。
• **字段修改审批**：修改“客户等级”或“合同金额”时触发审批。

审批流程设计要点

• **明确触发条件**：不是所有操作都需要审批。触发条件应清晰，例如“折扣率超过 10%”或“删除客户数超过 10 条”。
• **审批人可配置**：审批人可以是上级、指定角色或指定用户。最好支持“多级审批”，比如折扣超过 20% 需要总监审批。
• **审批状态与记录关联**：审批通过后，系统自动执行操作并更新记录状态。审批拒绝时，记录保持原样，并通知申请人。
• **超时自动处理**：如果审批人长时间未处理，系统可以自动转给备选审批人，或者默认拒绝。

审批的副作用

审批流程会降低效率。设计时要权衡：哪些操作必须审批，哪些可以事后审计。对于低风险操作（如修改跟进备注），建议只记录日志，不设审批。

操作日志：审计与追溯的基石

操作日志是权限系统的最后一道防线。即使权限配置有漏洞，完整的日志也能帮助事后定位问题。

需要记录的内容

每条操作日志应包含：

• 操作人（用户 ID 和姓名）
• 操作时间（精确到毫秒）
• 操作类型（创建、编辑、删除、导出、审批等）
• 操作对象（记录 ID 和类型，如客户 ID、合同 ID）
• 操作前后的数据变化（字段旧值和新值）
• 操作来源（Web 端、API、移动端）

日志的存储与查询

操作日志数据量很大。一个 200 人的销售团队，每天可能产生数万条日志。存储时建议：

• **分表存储**：按月份或按操作类型分表。
• **冷热分离**：近 3 个月的日志放在高性能存储，更早的日志归档到低成本存储。
• **索引优化**：为操作人、操作时间、操作对象建立索引，保证查询速度。

查询日志时，常见场景包括：

• 查看某个客户的所有操作记录。
• 查看某个用户今天的所有操作。
• 筛选某段时间内所有删除操作。

日志的保留期限

根据行业法规，CRM 操作日志通常保留 1 到 3 年。如果涉及金融或医疗行业，可能需要保留 5 年以上。系统应支持自动清理过期日志，并提供导出归档功能。

设计时的常见陷阱与建议

基于多个项目的经验，以下是容易忽略的问题：

1. 权限缓存与实时性

CRM 系统的角色和权限配置通常不会频繁变动，但一旦变更（比如销售主管离职，角色被移除），系统需要立即生效。如果权限信息缓存在内存中，需要设计缓存刷新机制。常见的做法是使用 Redis 缓存权限数据，并在角色或权限变更时发布消息，让所有服务节点刷新缓存。

2. 权限的继承与覆盖

如果用户拥有多个角色，权限冲突时怎么处理？建议遵循“取最大权限”原则。例如角色 A 允许“删除客户”，角色 B 不允许，那么用户最终可以删除。这个原则简单且符合直觉。

3. 性能问题

每次查询客户列表时，都要计算数据范围权限。如果数据量大（百万级客户），SQL 查询会变得很慢。优化方法包括：

• **预计算权限范围**：在用户登录时，将用户可访问的部门 ID 列表缓存到 Redis。
• **使用位图或标签**：给每条记录打上部门标签，查询时直接过滤标签。
• **限制单次查询数量**：CRM 列表页通常分页展示，每次查询 20-50 条，性能压力可控。

4. 测试与验证

权限系统是 CRM 中最容易出 bug 的部分。建议在开发完成后，编写自动化测试用例覆盖以下场景：

• 用户拥有多个角色时的权限叠加。
• 字段权限与数据范围冲突时的表现。
• 审批流程触发与拒绝后的数据状态。
• 操作日志的完整性和准确性。

总结与建议

权限设计没有银弹。每家公司对安全与效率的权衡不同，设计出来的方案也会不同。但有一些基本原则是通用的：

• **从简单开始**：初期只做角色和数据范围，字段权限和审批流程可以后续迭代。
• **保持可配置**：不要把权限规则写死在代码里，尽量做成管理后台可配置。
• **日志是底线**：即使权限有漏洞，完整的日志也能补救。日志系统一定要做好。

如果你正在规划 CRM 权限系统，建议先梳理业务场景：哪些角色需要哪些数据？哪些操作需要审批？哪些字段需要隔离？把这些问题想清楚，再动手设计。

SystemDo 在 CRM 定制项目中的经验是，权限方案需要先通过真实业务场景验证，再逐步增加字段权限和例外规则。能够被管理员解释、测试和审计的权限模型，通常比规则很多却无人说得清的模型更可靠。