工作流引擎组织结构设计：五张核心表支撑流程、低代码与权限

本文基于源码梳理一套工作流引擎的组织结构设计：五张核心表如何同时支撑流程选人、低代码数据权限与应用权限，并给出费用报销场景下的协同示例，供选型与实施参考。

开篇：组织结构的"一鱼三吃"

在企业数字化建设中，组织结构从来不是一张可有可无的通讯录——它是三件事的共同地基：

该 BPM 平台（该引擎）用 五张核心表（Port_Dept、Port_Emp、Port_Station、Port_DeptEmp、Port_DeptEmpStation）构建组织底座，使上述三大能力共享同一套组织语义——不必为流程建一套人、为低代码再建一套人、为权限又建第三套人。

这不是理论推演，而是写进引擎源码的工程选择。下文从流程、低代码、应用权限三个维度，说明其可取之处。

一、支撑工作流：让"按部门+角色找人"成为引擎本能

1.1 政企审批的真实语义

真实世界里的审批从来不是"找一个叫经理的人"，而是：

在「申请人所在部门」里，找「担任财务经理角色」的人。

同一个人，在 A 部门是经理，在 B 部门是普通员工——角色必须带部门上下文。该平台用 Port_DeptEmpStation 将 部门 × 角色 × 人员 三维绑定，与编制管理语义一致。

1.2 引擎直接消费，无需应用层翻译

该工作流引擎引擎 FindWorker 内置 20+ 种接收人规则（DeliveryWay 枚举），其中大量规则的核心查询直指五表：

核心选人 SQL 简洁到可以背诵：

SELECT FK_Emp FROM Port_DeptEmpStation
WHERE FK_Station = '角色编号' AND FK_Dept = '部门编号'

引擎还实现了智能向上找岗：本部门找不到人时，自动向父部门、同级部门回溯——这一整套逻辑建立在部门树（Port_Dept.ParentNo）与三要素绑定表之上，无需业务系统额外开发。

1.3 对流程实施的可取之处

• 配置即运行：流程设计器选"按角色"，底层自动查 Port_DeptEmpStation，实施顾问不必写 SQL。
• 兼职天然支持：一人多部门时，每个部门下的角色独立存储，流程不会"串岗"。
• 多组织零改模：集团/SAAS 模式下查询自动附加 OrgNo 条件，流程不因租户增加而重构。
• 可诊断：找不到人时，错误信息直指"某部门某角色下无人员"，便于核对组织数据而非猜引擎 Bug。

一句话：五表模型让流程引擎"理解"组织，而不是"绕过"组织。

二、支撑低代码：组织语义贯穿表单与应用全生命周期

低代码平台的承诺是业务人员可配置、少写代码。若组织模型与平台脱节，低代码就退化为"画界面 + 写脚本补权限"——该平台的做法是：把组织五表变成低代码的运行时上下文。

2.1 登录即携带完整组织身份

用户登录后，WebUser 上下文自动注入：

• WebUser.No — 人员编号
• WebUser.DeptNo — 主部门
• WebUser.OrgNo — 所属组织（集团/SAAS）
• 兼职部门与角色 — 运行时从 Port_DeptEmpStation 加载

低代码表单、流程、报表中的表达式（如 @WebUser.DeptNo、@WebUser.OrgNo）直接引用，无需每个应用重复封装用户服务。

2.2 表单控件原生理解组织

前端组件库（GPN_ComponentMapExt 等）内置多种组织感知控件：

• 按部门选人
• 按部门 + 岗位选人
• 组织树选择器

这些控件的数据源统一来自 Port_Dept、Port_Emp、Port_DeptEmpStation，设计器拖拽即可用，不必为每个表单写一套人员接口。

2.3 数据权限可视化配置，不靠写代码

该低代码平台单据（CCBill）提供 DBSafe 数据安全策略，在低代码界面中配置：

运行时，WF_CCBill 在渲染按钮权限前，自动查询当前用户的全部部门与角色：

随后据此判断当前用户能否新建、保存、删除、归档——全部在低代码配置层完成，业务开发者不必在每个 CRUD 接口里手写 if。

2.4 对低代码建设的可取之处

• 组织即平台能力：新建一个低代码应用，自动继承部门/角色/组织隔离，而非从零造轮子。
• 配置替代编码：权限策略在 GPN_DBSafe 界面点选，实施周期从"周"缩短到"小时"。
• 兼职场景不踩坑：权限计算遍历 Port_DeptEmpStation 中全部部门与角色，不会因只认主部门而越权或缺权。
• 集团/SAAS 原生：OrgOnly、Admin2（二级管理员）等策略与 Port_OrgAdminer 联动，一套低代码应用从单企业平滑扩展到多租户。

一句话：五表模型让低代码平台"自带组织智商"，而不是每个项目重新发明权限。

三、支撑应用系统权限：从菜单到数据行的统一坐标系

该 BPM 平台 的定位不仅是流程引擎，更是可嵌入业务系统的数字化底座。组织五表为应用级权限提供了统一坐标系。

3.1 三个层级的权限，一张组织底图

3.2 数据权限：部门、岗位、组织多维度组合

CheckDBRoleUtil 是应用数据权限的核心工具，支持按优先级叠加过滤：

• 全部（All） — 不限制
• 本部门（Dept） — 基于 DeptNo 字段过滤
• 部门领导（DeptLeader） — 查询 Port_Dept.Leader 是否为当前用户
• 本组织（OrgOnly） — 基于 OrgNo 字段隔离
• 父级组织及下级（NOrg） — 基于 Port_Org.TreeNos 层级
• 按表达式（Exp） — 支持 @WebUser.No 等组织变量

部门领导判断直接查组织表，而非维护独立"领导角色"：

3.3 管理权限：组织管理员体系

集团/SAAS 模式下，Port_OrgAdminer 定义二级管理员，可细化到：

• 流程目录权限（Port_OrgAdminerFlowSort）
• 表单目录权限（Port_OrgAdminerFrmTree）

WebUser.IsAdmin 运行时综合判断：超级管理员、组织主管理员、二级管理员——全部锚定在组织五表及其扩展表上，避免多套账号体系。

3.4 与业务系统集成：一套主数据，多处复用

业务系统通常已有 HR/OA 组织主数据。该平台提供两种集成路径，均围绕五表展开：

集成后，业务系统与 BPM/低代码/权限共用同一份组织真相，不会出现"HR 已调岗、流程还找旧人"的数据裂缝。

3.5 对应用权限的可取之处

• 统一语义：部门、岗位、组织在流程、表单、报表中含义一致，减少权限漏洞。
• 可审计：权限判断基于结构化组织数据，可追溯"谁在什么部门担任什么角色"。
• 租户硬隔离：OrgNo 贯穿五表，从数据行级别防止跨租户泄露。
• 渐进式增强：简单场景用部门字段即可；复杂场景叠加岗位、组织策略——不必一步到位上完整 IAM。

一句话：五表模型是应用权限的"共同语言"，而不是各模块各说各话。

四、三大能力协同：1 + 1 + 1 > 3

五表设计的真正价值，在于三件事共用同一底座时产生的协同效应：

场景示例：费用报销全流程

若组织模型分裂（流程一套人、权限另一套人），这个场景需要三处对齐、六套测试；该平台五表模型下，维护一次组织数据，三处同步受益。

五、与替代方案相比，优势在哪里

该平台五表不是"最简单的设计"，而是在流程、低代码、权限三域交叉点上，工程性价比最高的设计。

六、结语：选组织模型，就是选数字化底座

组织结构设计看似底层、枯燥，实则决定了：

• 流程能不能跑通；
• 低代码能不能真低代码；
• 权限能不能管得住。

该 BPM 平台 用五张表回答了一个工程问题：

如何用最小表集，让工作流引擎、低代码平台、应用权限系统共享同一套组织语义？

答案是：Port_Dept + Port_Emp + Port_Station + Port_DeptEmp + Port_DeptEmpStation——部门树、人员主档、角色定义、兼职关系、三要素绑定，缺一不可，亦不过度。

一套组织底座，三件事一次做对。 这是该平台十余年政企交付经验的沉淀，也是 该引擎 区别于"只会画流程图"的轻量产品的底层理由之一。