从客户管理案例出发拆开角色、数据范围、字段权限和操作权限上一篇我们把客户表和跟进记录做成了销售仪表盘。仪表盘让管理者能看到客户总数、阶段分布、来源分布和待跟进明细。系统变得更有用了但也马上带来一个更现实的问题这些数据应该所有人都能看到吗销售人员只应该看到自己负责的客户销售经理需要看到团队客户管理层关心全局指标但不一定要进入每一条跟进明细。客户电话、报价金额、合同备注、失败原因这些字段也不应该对所有人开放。所以企业数字化系统里权限不是上线前补一个“管理员开关”。它应该和数据模型、视图、仪表盘一样从业务开始就被设计进去。织信官方文档把平台定位为企业级 AI 信息化系统底座覆盖数据建模、流程自动化、权限治理、系统集成与 AI Agent 能力。入口可以参考织信企业级 AI 开发平台简介。这篇文章先不展开 AI而是把“权限治理”落到一个普通客户管理系统里看。权限不是一个开关很多人第一次做权限会先建两个角色管理员和普通用户。这个设计看似简单实际很快会失控。普通用户里有销售、销售主管、销售经理、市场人员、财务人员和老板他们对同一张客户表的需求完全不同。如果只靠“管理员/普通用户”区分要么权限太大大家都能看到不该看的数据要么权限太小业务推进时到处找管理员帮忙。更合理的做法是把权限拆成一条判断链客户管理中的权限判断链路当一个用户打开客户表时系统至少要回答四个问题这个人是什么角色这个角色能看哪些记录这些记录里哪些字段可以显示页面上的新增、编辑、删除、导出等动作是否允许最终结果不是“能不能进系统”而是“这个人在当前页面能看到什么、能改什么、能继续做什么”。从三个角色开始建模权限设计不应该从技术名词开始而应该从组织中的真实职责开始。在客户管理案例中可以先定义三个角色角色典型职责权限设计目标销售人员维护自己负责的客户记录跟进动作只能处理自己的客户减少越权查看销售经理分配客户、检查团队推进情况、复盘销售阶段能看团队数据能调整负责人和阶段管理层看整体经营情况、关注关键指标和风险能看全局汇总谨慎开放明细操作这三个角色不是为了做组织架构而是为了回答“系统应该怎样为不同人呈现同一份数据”。三类角色查看客户数据的权限矩阵如果角色定义清楚后面的数据范围、字段权限和操作权限就不再是拍脑袋。数据范围谁能看到哪些记录数据范围解决的是“哪些行对这个人可见”。在客户表里最常见的规则是按负责人过滤销售人员负责人 当前用户 销售经理负责人属于当前团队 管理层不限制负责人查看全部客户这和数据库查询里的where条件很像。区别在于权限条件不是用户手工筛选出来的而是系统根据当前登录用户和角色自动加上的。例如销售张三打开“客户明细”视图时看到的是负责人为张三的客户销售经理打开同一张表时看到的是团队成员负责的客户老板打开仪表盘时看到的是全公司客户汇总。同一张客户表没有复制三份只是不同角色进入时系统加了不同的数据范围规则。这一点很关键权限不是通过复制数据实现的而是通过统一数据源上的访问规则实现的。字段权限不是每一列都应该展示数据范围解决“能看哪些客户”字段权限解决“能看客户的哪些信息”。客户名称、行业、当前阶段、负责人这类字段通常属于业务基础信息可以给销售和经理查看。手机号、邮箱、合同金额、报价底线、失败原因、关键联系人私人信息则可能需要更严格控制。可以用一个简单规则设计字段可见性字段类型示例字段建议权限基础识别字段客户名称、行业、来源销售、经理、管理层可见推进状态字段当前阶段、负责人、下次跟进时间销售和经理可见管理层看汇总联系方式字段手机号、邮箱、联系人微信负责销售和经理可见商务敏感字段报价金额、折扣底线、合同备注经理或授权角色可见复盘字段失败原因、流失原因经理和管理层可见字段权限最容易被忽略。很多系统只控制“能不能打开客户表”却不控制“打开后能不能看到手机号和金额”。结果是数据范围看似没问题敏感信息却在列表、导出、仪表盘明细里泄露了。开发者理解字段权限可以把它看成响应数据的裁剪。不是前端把列隐藏一下就结束而是后端、接口、页面和导出都要遵守同一套规则。操作权限能看不代表能改第三层是操作权限。能看到一条客户记录不代表可以随意修改。客户管理里常见动作包括新增客户编辑客户基础信息修改客户阶段分配或转移负责人新增跟进记录删除客户导出客户数据。这些动作应该分开设计。销售人员可以新增跟进记录、更新自己客户的阶段但不一定能删除客户。销售经理可以调整负责人、修正阶段、查看团队跟进但删除客户和批量导出应该更谨慎。管理层可以查看全局数据和导出报表但不一定参与日常维护。这里有一个很重要的原则删除和导出永远不要因为“方便”就默认开放。删除会破坏追踪链导出会把系统内的权限边界带到系统外。企业系统越依赖数据越要把这些动作当成高风险操作。视图和仪表盘也要受权限约束前几篇文章里我们已经做了客户表格、阶段看板、跟进日历和销售仪表盘。权限不是只作用在表单详情页也应该作用在这些入口上。例如“我的客户”视图默认只显示当前销售负责的客户“团队客户”视图只对销售经理开放“销售管理驾驶舱”中的客户总数销售看到个人范围经理看到团队范围管理层看到全局范围仪表盘里的明细卡片如果包含手机号或合同金额也要遵守字段权限。这也是为什么权限要和数据模型一起设计。如果仪表盘直接读取客户表但没有继承数据范围规则销售就可能通过仪表盘看到全公司客户数量和明细如果导出按钮绕过字段权限页面上隐藏手机号也没有意义。一个可靠的权限模型应该让表格、看板、日历、仪表盘、表单、接口和导出都基于同一套判断。权限验证要用具体账号测试权限不能只靠配置完成后“看起来差不多”。它必须测试。最简单的验证方法是准备三类测试账号测试账号角色验证点zhangsan销售人员只能看到自己负责的客户不能删除客户manager销售经理能看到团队客户能分配负责人boss管理层能看全局指标但不参与普通客户维护然后针对同一条客户记录做检查把客户负责人设为张三用张三登录确认可以看到并新增跟进记录用另一个销售登录确认看不到这条客户用销售经理登录确认能看到并调整负责人用管理层账号查看仪表盘确认看到的是汇总指标检查手机号、金额、导出、删除等敏感字段和动作是否符合预期。权限验证的核心不是“页面有没有报错”而是“越权路径有没有被堵住”。尤其要检查列表、详情、仪表盘、导出和接口这几条路径是否一致。常见误区第一个误区是把管理员当成权限设计。管理员只是系统维护角色不应该替代业务角色。真正的业务权限要从销售、经理、财务、管理层这些职责出发。第二个误区是只控制菜单不控制数据。隐藏一个菜单并不等于数据安全。如果接口、仪表盘或导出仍能拿到数据权限就没有闭环。第三个误区是只控制记录不控制字段。客户记录可以看不代表手机号、金额和敏感备注都应该看。第四个误区是忘记测试。权限配置越复杂越需要用不同账号验证。不要只用管理员账号验收企业系统。从权限走向流程到这里我们的客户管理系统已经有了数据表、视图、仪表盘和权限模型。权限回答的是“谁能看、谁能改”。但企业系统还需要继续回答另一个问题当一件事需要多人协作时系统如何推动它一步步完成比如请假申请需要员工提交、主管审批、人事备案客户折扣申请需要销售发起、经理审核、财务确认。每一步都要知道当前状态、负责人、处理时间和历史记录。下一篇我们进入工作流请假审批如何实现全过程追踪。权限会继续发挥作用因为流程里的每一步本质上也在回答“当前这个人能不能处理这件事”。