简介这份《泛微OA流程搭建操作流程》PDF文档面向泛微OA系统管理员、实施顾问及企业信息化人员帮助缺少开发经验者按步骤完成业务表单与审批流程搭建解决流程配置零散、节点权限不清、表单模板不统一等问题。全包仅1个PDF文件约1.39MB按实际操作路径组织涵盖新建表单与字段批量添加、路径绑定自定义表单、流转节点与操作组配置、表单内容Html模式初始化模板、同步节点、退回设置、节点前附加操作等环节并穿插标题样式、行高调整、图片插入与审批矩阵等实用细节。已有3308人学习说明其在OA实施与运维场景中具有较高参考价值。读者可把它当作一份可对照后台界面的速查手册快速理解从建表、绑路径到节点流转与归档只读的完整链路减少试错成本也便于在项目交付时统一配置规范、排查常见问题。1. 泛微OA流程搭建不是画连线而是把单据规则翻译成配置业务部门常说「就是一张请假单部门经理批完人事批」你在流程设计器里连好几条线发布第二天却收到反馈提交后单据卡在第一个节点谁都点不了批准。问题通常不在连线而在背后三件没配齐的东西——表单字段有没有真正落库、节点操作者有没有绑定到具体的人、出口条件是不是把所有人都挡在门外。泛微OA流程搭建的本质是把线下签批的规则翻译成表单、节点、出口三套可执行配置图画得再漂亮规则没落地就等于没搭。这篇内容面向 OA 管理员、实施顾问和要跟业务方对接的 IT按「先定模型、再动手配、最后用真实单据验」的顺序推进也会覆盖条件分支、子流程和归档后回写外部系统这些绕不开的点。2. 泛微OA流程搭建前的模型设计表单、节点与出口怎么定动手点鼠标之前真正决定这条流程能不能一次配通的是三张纸上的东西字段清单、节点清单、出口规则。业务方给的需求往往是口语化的「超过三天要找总监」要把它拆成系统认得的形式就得先确定天数存在哪个字段、放在哪个节点、用什么条件判断。这一步花掉的时间通常比在后台点配置的时间还多但能省掉后续反复改流程的返工。2.1 用「单据—节点—出口」三层模型拆解一条流程我一般把一条流程拆成三层来跟业务方对齐。第一层是单据也就是表单上要填的字段它决定数据长什么样、后续能被谁统计第二层是节点也就是「谁在什么时候看到这张单据能按哪些按钮」第三层是出口也就是「满足什么条件走哪条线不满足走哪条线」。三层之外还有一个容易被忽略的东西字段在不同节点上的权限差异比如申请人可编辑的金额字段到审批人那里必须锁成只读否则审批流就失去了意义。跟业务方过需求时我固定问四组问题单据上必须填的信息有哪些哪些是选填每一级审批由岗位决定还是由人决定岗位空缺时谁来兜底什么情况下需要跳级或者加签审批完成后数据要落到哪个模块、要不要推给外部系统。这四组问题的答案基本就构成了后面所有配置的输入写成一页纸贴在旁边配置的时候不用来回翻聊天记录。2.2 表单字段设计主表、明细表和字段类型该怎么选字段设计最容易出问题的地方是「能用文本就不用其它类型」。文本字段看起来万能实际上在出口条件判断和报表统计时全是坑比如「金额」用文本存条件里做大于比较会变成字符串比较。下面这张表是我常用的字段类型对应关系可以当成一张对照表用。业务含义推荐字段类型常见坑单据编号单行文本配置自动编号规则手工填写导致重号申请人、审批人人员浏览框存姓名不存 ID人离职后无法匹配所属部门部门浏览框多部门兼职时取值不确定金额、天数数字精度按业务定文本存储导致条件比较失效申请类型下拉框固定枚举选项文案改动后历史单据条件判断错位费用明细明细表明细行数不固定主表条件无法直接引用附件附件字段归档后附件权限没同步明细表是新手最容易踩坑的一块。明细表里的字段不能直接写在主表的出口条件里常见做法是在主表上放一个「合计金额」或「是否超标」的汇总字段由表单脚本或计算规则把明细汇总上去出口条件只判断主表这个字段。这样配置简单条件也稳定不会因为明细行数变化导致判断结果飘忽。2.3 节点操作者的四种绑定方式与适用边界节点审批人怎么绑决定了这条流程在不同部门、不同人手下能不能跑得通。泛微OA 里常见的绑定方式大致有四类各有自己的边界。绑定方式典型配置适用场景风险固定人员/角色直接指定用户或挂角色流程固定、审批人变化少人调岗后流程失效组织维度按部门负责人、上级部门行政、人事类通用流程部门负责人空缺时无人可批按表单字段取申请人上级、表单中选择的人业务线差异大、审批人动态字段为空时节点挂起人员矩阵岗位与部门交叉取人多组织、多岗位的大型集团矩阵未维护时取不到人实际项目里很少只用一种。我的习惯是第一级审批用「申请人上级」这种关系型取值中间的专业审批财务、法务用角色最后归档给固定的归档员。每一类都配一个兜底人或者兜底角色避免节假日、离职这种场景把单据卡死。2.4 出口条件与流转顺序先定规则再画线出口条件不是写完一条算一条它是一组必须互斥且完整的规则。互斥指的是同一张单据不能同时满足两条出口完整指的是所有可能取值都有出口可走。判断是否互斥有个笨但有效的方法把条件涉及的字段取值列成真值表逐行看会不会同时命中两条。配置顺序上我一般把条件最严格的出口排在上面把最宽松的默认出口放最后。另外要明确一点默认出口不能省略它是整个节点的兜底路径。如果所有条件出口都不满足又没有默认出口提交时系统会直接报「找不到可用出口」这是新手最常见的发布失败原因。3. 在泛微OA后台把一条流程从空白配到发布模型定好之后剩下的就是在后台把配置填进去。这一章按实际操作顺序走新建流程、配表单字段、配节点和按钮、写出入口条件最后发布。每一步我都会说清参数的作用因为同一套界面里参数改一个字流程的行为可能完全不同。3.1 新建流程与流程属性的必填项进入后台的流程管理新建一条流程先填流程名称、流程编号、所属分类和关联的表单或建模模块。流程名称建议带上业务标识比如「XX公司-请假申请」因为后续做流程查询和统计时名称是主要的筛选条件。流程编号一般用于接口调用和日志排查不要随意改改完之后老单据的查询脚本会全部失效。流程属性里有几个参数值得留意是否允许撤回、撤回时限、是否允许流程发起人看到全部节点、归档后是否允许修改。撤回时限设得太长会让审批人对已批单据失去安全感我一般设成十分钟到一个小时之间归档后是否允许修改取决于这张单据是否参与财务对账如果参与就要额外走一条变更流程而不是直接改。3.2 表单字段的落库与节点级显示控制字段配置分两步先定义字段本身再定义字段在各个节点上的权限。字段本身要填字段名称、字段编码、类型、长度、是否必填、默认值。字段编码是出口条件和接口里引用的唯一标识建议用业务英文缩写配完之后尽量别改。默认值可以减轻填写负担比如申请日期默认为当天、申请人默认为当前登录用户。节点级权限是很多人漏掉的一步。同一个字段在不同节点上可以是只读、可编辑或者隐藏。判断原则很简单这个节点的人是否需要为这个字段的真实性负责。需要负责的给他编辑权只是查看的锁成只读完全无关的直接隐藏。字段权限没配好会出现审批人随手改金额却没人发现的情况事后追溯很麻烦。3.3 节点配置审批人、按钮、超时与代理节点配置从类型开始创建节点、审批节点、归档节点各自的含义不同创建节点决定谁能发起归档节点决定数据最终落到哪里。节点操作者按第二章说的四种方式绑定绑完之后一定要用「查看实际人员」之类的预览功能点一下确认取到的是活人而不是空集合。按钮是节点上另一组关键配置。审批节点常见按钮有批准、退回、转办、加签、意见征询每个按钮对应的动作要在节点里勾选没勾的按钮不会出现在审批人的界面上。退回还要单独设「退回到哪个节点」退到上一节点和退到创建节点在业务上差别很大。超时提醒可以设提醒时间与提醒对象代理规则则用于请假、出差场景让代理人临时接管待办。3.4 出口条件表达式怎么写出口条件可以理解为一段判断判断的输入是表单字段输出是「走这条线还是不走」。多数版本都提供条件构建器点名字段、选运算符、填比较值即可也支持手写表达式。下面用请假场景举例请假天数大于三天走总监审批否则直接到人事备案。// 出口一走总监审批 // 条件构建器配置字段 leaveDays运算符 大于比较值 3 // 手写表达式形式以本环境实际语法为准 return $leaveDays$ 3; // 出口二默认出口放在条件出口之后不写条件 // 表示上面条件都不满足时走这里配置时要注意三点。第一比较值的数据类型要和字段类型一致数字字段填3而不是3否则可能出现判断失效。第二多个出口的执行顺序由上到下第一条命中即停所以条件之间必须互斥。第三条件里引用的字段必须在该节点已经产生值如果字段在审批节点才填写却在创建节点后的出口里判断取值一定是空的。3.5 保存、发布与版本改流程的正确姿势流程编辑页面上的「保存」和「发布」是两个不同动作。保存只是把配置存成草稿不会影响正在跑的实例发布才会生成一个新版本之后新发起的单据走新版本已经发起的单据继续走它发起时的旧版本。这一点很关键线上改流程不会污染历史单据但也不会自动把老单据迁移过来。如果确实需要让老单据走新路径常见做法是让用户撤回重提或者由管理员在后台做节点跳转。跳转要谨慎跳完的日志会记录下来事后对账时要能解释清楚是谁、什么时候、为什么跳的。测试环境里改流程可以随意生产环境我一般会先在测试环境完整跑一遍再选在业务低峰期发布。4. 流程上线前用真实单据跑通全路径配置发布完不等于能上线。真正能说明问题的是拿三个不同身份的账号把单据从发起到归档完整跑一遍再故意制造几次异常看系统怎么反应。这一章讲测试账号怎么准备、用 SQL 怎么查实例卡在哪、遇到问题看什么表以及怎么用接口批量造测试数据。4.1 测试账号与角色准备最少准备三类账号发起人账号、中间审批人账号、归档人账号。如果流程有部门差异还要准备两个不同部门的发起人验证组织维度取值是否正确。如果用了角色绑定要额外准备一个「角色为空」的场景看看系统是报错还是把待办推到兜底人身上这个场景在生产上一定会遇到。测试时用真实的业务数据不要用「测试1」「测试2」这种占位符因为下拉框选项和业务规则往往对具体值敏感。每次测试完保留单据编号出问题时能直接拿编号去后台查日志。测试单据建议只发给自己和几个同事不要发到真实领导那里避免不必要的工作量。4.2 用 SQL 查流程实例卡在哪个节点单据卡住时光看界面往往看不出原因得直接查库。泛微OA 的工作流相关表在不同版本里有差异下面这段 SQL 的思路是通用的从流程实例主表关联当前操作者表再关联节点表就能看出这个实例现在挂在谁手里。-- 查询某个流程实例当前的待办节点与操作者 SELECT r.requestid, r.requestname, n.nodename AS 当前节点, u.lastname AS 待办人, o.receivedate AS 到达时间 FROM workflow_requestbase r JOIN workflow_currentoperator o ON o.requestid r.requestid LEFT JOIN workflow_nodebase n ON n.id o.nodeid LEFT JOIN hrmresource u ON u.id o.userid WHERE r.requestid 100001 ORDER BY o.receivedate DESC;表名和字段名请以自己环境为准不同版本的表结构会有差别。如果这条查询返回空结果说明实例的当前操作者记录不完整通常意味着出口条件配置有误或者节点操作者取值为空。下面这张表是我排查卡点时的常用对照。现象可能原因先查什么提交后无待办出口条件不满足且无默认出口出口条件配置与字段取值待办人显示为空组织维度取到空负责人部门的负责人字段只有部分人能看到角色或分部范围不匹配角色成员与分部配置退回后回到错误节点退回目标节点配置错误节点退回设置归档后数据缺失归档动作未绑定数据写入归档节点的后续动作4.3 用接口批量发起测试单据手工造几十张单据很浪费时间用接口批量发起效率高得多。泛微OA 对外提供流程相关接口路径和参数在不同版本里不一样具体以本环境的接口文档为准。下面这段 curl 只是示意调用结构重点看参数怎么组织。# 步骤一登录换取 token curl -s -X POST http://oa.example.com/api/login \ -H Content-Type: application/json \ -d {loginid:testuser,password:******} # 步骤二带 token 发起流程 # workflowId 是流程定义编号data 里放表单字段编码与值 curl -s -X POST http://oa.example.com/api/workflow/start \ -H Authorization: Bearer ${TOKEN} \ -H Content-Type: application/json \ -d { workflowId: LEAVE_001, creator: testuser, data: { leaveType: 事假, leaveDays: 5, reason: 接口联调测试 } }参数说明workflowId对应第 3.1 节里填的流程编号creator必须是系统里存在的登录账号data的键是字段编码不是字段名称写错编码接口会直接忽略该字段而不一定报错所以发起后要回后台核对单据上字段是否有值。批量测试时把 data 部分换成变量循环调用即可注意控制频率避免对生产环境造成压力。5. 泛微OA流程搭建的进阶用法条件分支、子流程与外部回写流程能跑通之后接下来要解决的是「不同情况怎么走不同路」和「数据怎么流出去」。这两件事做得好OA 才算真正嵌进业务里而不是一个孤立的审批工具。5.1 一表多流程与条件分支的选择同一个业务对象可能有多种走法比如采购申请按金额分普通和重大两类。有两种实现方式一种是建两条独立流程各自挂不同的表单另一种是一条流程内部用条件出口分流。判断标准是有多少配置差异。如果两条流程的字段、节点、审批人几乎相同只是节点数量不同用条件出口更省维护成本如果审批角色、表单字段差异很大就拆成两条流程各自独立互不影响。拆流程时要处理一个细节入口怎么区分。常见做法是在门户或建模模块上放两个入口按钮或者让用户先选申请类型由表单脚本跳转到对应流程。后者体验好一点但脚本要维护好跳转逻辑字段变化时容易漏改。5.2 子流程与触发式流程子流程适用于「主流程走到某一步需要另起一条独立审批」的场景比如主流程是项目立项中途需要单独走一次预算审批。子流程有自己独立的实例编号和审批链主流程可以等待子流程归档后再继续也可以并行推进取决于业务上是否需要卡住。配置子流程要关注两点。一是父子流程之间的数据传递通常是把主流程的字段值带过去作为子流程的初始值二是归档回写子流程归档后要把结果比如审批结论、金额写回主流程的对应字段供后续出口条件判断。没做回写主流程的后续分支就失去了判断依据。5.3 归档后的数据回写与外部系统对接流程归档后数据往往还要推给外部系统比如财务系统的凭证、ERP 里的采购订单。这类对接有两种常见做法一种是归档节点上挂后续动作直接调用接口另一种是把归档数据落到中间表由外部系统定时来取。前者实时性好但接口失败时会影响流程归档后者更稳代价是有延迟异常也更容易重跑。接口回写要注意幂等。同一个单据如果被重复触发归档动作外部系统不能生成两条记录通常用流程实例编号加动作类型作为唯一键来处理。失败重试要有次数上限和告警不然一张单据卡住没人知道月底对账时才发现少了一条数据。5.4 线上改流程的安全姿势最后说一个复用性很高的技巧出口条件里尽量不要直接引用选项的文案。下拉框选项的显示文案经常被业务方要求改措辞而条件判断若按文案匹配改一个字就全线失效。稳妥的做法是让选项背后带一个不变的值比如编码条件按值判断文案随便改。同样的思路也适用于人员字段和部门字段永远按内部标识匹配不按名称匹配。配置完一批条件后用真值表把每条出口走一遍比上线后靠用户报错快得多。本文还有配套的精品资源点击获取