多组织架构下的数据权限，本质是回答一个问题：同一个系统里，谁在什么组织范围内、能看和能改哪些数据。常见做法是先按角色分功能权限，再用组织范围和数据行规则收窄可见记录数。三种主流路线各有代价，选错往往不是权限没做对，而是后期每加一个组织都要改代码。
方案一：纯角色权限，用角色区分组织可见范围
最直接的做法是把组织维度合并进角色，例如「华东销售主管」「华南销售主管」各建一个角色，功能权限相同，可见数据范围由角色绑定。开发量小，上线快，业务人员也容易理解。
- 优点：模型简单，不需要额外的数据范围表，配置界面直观，排查问题时一眼能看出是哪个角色给多了权限。
- 优点：适合组织数量固定、调整频率低的场景，例如集团下属若干家子公司、各自业务相对独立。
- 缺点：角色数量随组织数增长而膨胀，组织一调整就要新建或合并角色，容易出现遗漏。
- 缺点：同一个人跨两个组织任职时，授权关系难以表达，只能靠多角色叠加，叠加后的实际可见范围不易核对。
这条路线适合组织架构稳定的政企单位，但对处在重组、并购期的集团不太友好。若后续要接入流程审批、报表共享，权限口径会不断扩散，维护成本上升很快。
方案二：角色加数据行规则，功能与数据范围分离
更常见的工程做法是把功能权限和数据范围拆开：角色只管「能进哪个菜单、能点哪个按钮」，数据范围由一组规则决定，规则可以按组织树、按负责人、按创建人、按部门归属等条件组合。
- 优点：组织调整只改组织树和规则，不动角色；新增组织时通常只需配置，不需要发版。
- 优点：数据范围可以被多个角色复用，跨组织任职用多条范围规则并集表达，结果可回溯。
- 缺点：规则越灵活，越需要明确优先级和并集、交集语义，否则同一用户在不同模块看到的范围不一致。
- 缺点：行级过滤通常要落到查询条件里，数据量大时要配合索引设计，否则列表页会变慢。
实施时建议先固定几个标准范围类型，例如本部门、本部门及下级、指定组织、仅本人，把自由配置的口子留给少数场景。这样既保留了灵活性，也避免规则失控。需要把权限模型和现有业务系统对接时，可以参考我们的软件定制开发与系统集成服务，重点是先梳理组织与权限体系，再动代码。
方案三：组织维度加业务标签的混合模型
当数据本身带有业务归属，例如客户归属、项目归属、供应商归属，单靠组织树往往表达不了「数据跟着业务走」的需求。混合模型在组织维度之外再加一层业务标签，两者取交集或并集。
- 优点：能覆盖矩阵式组织，例如一个人属于某分公司，同时参与集团级项目，两类数据的可见逻辑可以分别定义。
- 优点：数据随业务转移时，改标签即可，不必调整人员岗位关系。
- 缺点：需要在业务表上维护标签字段，历史数据要清洗补齐，工作量集中在前期。
- 缺点：模型抽象度高，业务方不容易理解，必须配可视化预览，让管理员看到「这个账号实际能看到哪些数据」。
这条路线适合集团型制造、物流与供应链企业，组织与项目交叉较多。我们在物流与供应链项目案例中遇到的权限诉求，多数属于这一类：数据归属随业务流转，而不是固定挂在某个部门下。
什么情况下不要选这些方案
选型不只是选对的，也是排除错的。以下情形建议直接跳过对应方案，避免返工。
- 组织数量处在快速变化期，不要选纯角色方案。每调整一次组织就新建角色，半年后权限表会难以维护。
- 只需要区分「本人」和「本部门」两级可见范围时，不要上混合模型。抽象层过多，配置和排查成本都高于收益。
- 数据表规模大且查询频繁的业务列表，行级规则不要做成运行时逐条判断，应在查询条件中下推，否则页面响应会明显变慢。
- 没有组织主数据、部门归属靠人工填写的系统，不要先做数据权限。数据本身不可信时，权限做得越细，错误越明显。
- 涉及跨单位报表汇总且各方对口径敏感时，不要只靠前端隐藏数据，权限必须在服务端和查询层同时生效。
落地时的几个工程判断点
无论选哪种方案，有几处判断点建议在需求调研阶段就写进方案，后面验收有据可依。
- 组织树是否唯一：一个人多岗、一个部门多上级的情况要提前确认，否则范围计算会出现歧义。
- 权限变更的生效时机：是下次登录生效还是实时生效，涉及缓存设计，需要和业务方对齐。
- 授权结果的核对方式：建议提供「以某账号预览可见数据」的功能，验收时逐条核对，比看配置页更可靠。
- 与流程、报表的口径统一：审批流的可见范围与列表页的可见范围应使用同一套规则，避免两处各写一套。
如果系统里已有国产 OA 承接流程，权限设计通常要兼顾 OA 的组织与角色体系。我们的做法是先梳理组织与权限口径，再做流程与表单定制、与 ERP/HR 等系统对接；具体交付阶段见服务范围与交付流程。POC 阶段建议用真实组织数据和几类典型角色跑一遍，确认可见范围符合预期再进入开发。
验收清单与方案对比
上线前可以按下面几项自查：组织调整后是否需要改代码；跨组织任职用户的可见范围是否可解释；列表页在大数据量下的响应是否可接受；权限规则是否存在多处重复定义；是否有账号预览与变更审计。这几项过了，权限模型基本站得住。
文字版对比清单，每行一组「方案 → 适合谁 → 主要代价」：
- 纯角色权限 → 组织稳定、规模不大的单位 → 角色数量随组织增长，跨组织任职难表达。
- 角色加数据行规则 → 组织会调整、系统需长期演进的集团 → 规则语义要先定清楚，查询性能需专门优化。
- 组织维度加业务标签的混合模型 → 矩阵式组织、数据随业务流转的企业 → 前期数据清洗与标签维护工作量大，配置门槛高。
- 暂不做细粒度权限、先补组织主数据 → 基础数据尚不可信的系统 → 需要先投入数据治理，权限上线时间后移。
数据权限没有一劳永逸的模型，关键是让组织、角色、数据范围三者的关系可解释、可配置、可核对。需要结合现有系统评估路线时，可以先看我们的同类项目案例，再决定从哪一层开始改。
