简介蓝凌标准产品V16.0管理员手册——流程表单篇专为企业OA系统管理员、流程运维人员及二次开发者编写聚焦工作流引擎的核心配置与管理操作。手册从通用流程模板设置入手系统讲解流程基本信息定义、操作栏图标配置、节点类型划分与操作方式说明并借助泳道图帮助管理员快速理清跨部门流转路径。针对实际审批场景手册分别对审批、签字、抄送、人工决策、条件分支、机器人、启动/回收子流程、并行分支、自由子流程及投票节点逐一展开说明覆盖流程编排中可能遇到的主流节点功能配套196页图文讲解便于按需查阅。资源以1个PDF文件打包整体约20.65MB适合在实施或运维蓝凌OA时作为现场参考手册使用。当前已有2348人学习下载内容贴合V16.0标准产品日常流程维护与优化场景。1. 流程表单到底是什么管理员手册里最容易被低估的一章接手一套 OA 系统后大概率会经历这种场景业务部门提了个需求说报销单要加一个“是否差旅”的选项选了“是”之后要多填一段行程明细。听起来是个小改动实际动起手来却发现表单改完了流程里选不到新字段字段好不容易出来了发起人又看不见等全部调通业务方已经改了三次需求。这时候翻到“蓝凌标准产品V16.0管理员手册-流程表单.pdf”这一章才会意识到它不是一份简单的表单制作教程而是把表单建模、流程绑定、节点参数、版本管理串在一起的整套配置方法论。流程表单解决的核心问题只有一个让管理员不写代码就能把“一张单子走完一条流程”这件事配置出来并且能在后续业务变化时低成本调整。它的适用人群很明确——OA 系统的实施顾问、刚接手系统的管理员、以及需要独立搭建审批流程的业务信息化接口人。这篇笔记不打算复述手册原文而是按我实际配置流程的路径从表单和流程的关系讲起一路说到参数设置、常见坑和进阶技巧希望能帮你少走几趟弯路。2. 流程表单的底层关系表单、流程定义与流程实例是怎么串起来的2.1 表单模型、流程定义与实例数据三者各自的归属很多刚接触 OA 配置的管理员会有一个思维惯性把一张表单当成一条流程。实际上在流程表单的设计里这三者是分离的。表单模型负责收集数据定义“有哪些字段、字段什么类型、布局长什么样”流程定义负责控制流转定义“谁发起、经过哪些节点、每个节点谁审批、满足什么条件跳到哪里”而流程实例是某一次具体的业务单据它是发起那一刻对表单和流程的“快照”。理解这套关系最好的切入点是版本。表单模型有版本流程定义也有版本而流程实例一旦发起它锁定的就是当时的表单版本和流程版本。这意味着管理员改了表单字段或者调整了审批路径已经发起的单据不会跟着变。这个设计初看有点反直觉但细想是对的——如果流程走到一半表单结构变了那审批人看到的数据就乱了打印出来的单据也对不上。我一般会在配置前先和业务方把这条规则讲清楚需求变更只影响新发起的单据存量单据按旧版走完。这么一说很多“为什么我刚改完流程之前的单子还在走老路径”的疑问就迎刃而解了。理解了这个底层关系后面所有关于绑定、字段引用、历史数据查询的配置才说得通。2.2 表单与流程的绑定入口配置顺序怎么排在标准产品里表单和流程的绑定发生在流程设计的起始环节。常见做法是先建表单模型再建流程定义最后在流程定义里指定“发起时使用哪个表单”。这里要注意一个细节表单可以在多个流程里复用而一个流程通常只绑定一个主表单复杂的业务则通过子表单、明细表或者关联表单来扩展。配置顺序我建议固定为三步走。第一步梳理表单字段把业务要填的内容拆成字段维度明确哪些是基础信息、哪些是明细数据、哪些是审批过程中才补充的意见第二步画流程草图把节点和连线画出来标注每个节点的审批人类型第三步才是进系统配置先建表单、再建流程、最后绑定并测试。如果顺序反过来经常会出现流程建好了、表单字段没对齐返工的工程量会很大。绑定前后还有两个容易忽略的位置。一个是流程表单的“发起字段可见性”设置它决定发起人在发起页能看到哪些字段比如“审批意见”这类字段在发起页就不该出现另一个是各个审批节点上的字段权限比如普通员工提交后审批人能不能修改某些字段。这两项都依赖表单和流程绑定完成后才能配置所以绑定动作是整个流程表单配置链路里的枢纽。3. 从零配置一张请假审批单建模到发布的完整步骤3.1 表单建模字段类型与布局的取舍表单建模是流程表单里最不需要技术含量、却最需要业务判断的环节。常见误区是把业务方口头描述的所有内容都做成字段结果一张单子几十个字段填写人烦、审批人也烦。我一般会先按“填写成本”和“审批关注度”两个维度筛一遍字段能通过数据联动带出来的不要手填审批过程里用不到的不要放主表。字段类型的选择直接影响后面的流程条件配置。日期、金额这类字段有明确的类型语义下拉框和单选适合做条件分支而文本框要谨慎用于流程条件因为文本比较容易踩坑用户输入一个空格、一个全角字符条件判断就会偏离预期。明细表字段适合行程、费用清单这类一对多数据但明细表里的字段不能直接参与主流程的条件判断需要先做数据汇总或者通过脚本取值。布局上要留有余地。表单设计时每个字段的排列顺序、是否换行、是否必填都会影响发起人体验。有一个实用的经验是把“发起人信息”“表单主题”“审批意见”这类共性字段放在统一位置这样所有流程的审批界面风格一致审批人切换到不同单据时不需要重新适应。我还会在表单里预留一两个扩展字段比如“备注”或“自定义编号”备着业务后续加规则时用避免每次小改动都要发布新版本。3.2 流程设计节点、连线与审批动作的配置逻辑流程设计的第一步是确定节点数量。很多新手把流程画得很长每个部门一个节点甚至同一部门多个节点导致审批周期被拉得很长。常见做法是能合并的节点就合并同一个审批人在连续节点出现时合并成一个节点或配置自动跳过。节点的核心配置项有三个审批人来源、审批动作、字段权限。审批人来源可以是固定人员、角色、部门负责人、发起人自己或者表单字段里的某个人员字段。这几种来源的适用场景不同——固定人员适合行政类流程角色适合会签类流程表单字段人员适合“员工自选审批人”的业务。审批动作则包括同意、拒绝、转办、加签、退回这决定了审批人手里的操作按钮有哪些。连线上最重要的是条件设置。流程从 A 节点到 B 节点还是 C 节点不是看业务方口述而是看连线上的条件表达式。条件表达式支持字段比较、逻辑与或例如“请假天数大于 3 且请假类型等于年假”。这里我会提醒一点条件表达式是在表单字段基础上做的字段必须是流程表单里真实存在的字段别拿计算列或者明细表字段来写主流程条件。3.3 发布与版本管理为什么不能只留最新版流程设计完成后需要发布发布动作会把当前表单版本和流程定义绑定成一套可用的组合。发布不是一次性工作后续每次调整都要重新发布而且推荐保留历史版本而不是覆盖。版本管理带来的最大好处是可回滚。有一次我给某公司调整合同审批流把会签比例从 50% 改成 100%发布后业务方反馈流程走不动因为会签人数是单数时 100% 比例下无法达成一致。回滚过程很简单——把历史版本重新发布启用实例恢复走旧规则。如果没有保留历史版本这个回滚就不存在只能重新配置一遍那种焦虑感经历过的人会懂。发布后的自测步骤我建议用一个最小的巡检脚本通过产品的管理接口或后台数据表确认表单和流程的绑定关系没有串。以常见的管理接口为例可以用下面的方式检查流程定义与表单的绑定是否正确。# 假设管理端提供了查询流程定义详情的接口 # 参数 process_key 为流程定义标识返回结果里关注 form_key 字段 curl -X GET http://server/api/admin/process/definitions/{process_key} \ -H Authorization: Bearer token \ -H Content-Type: application/json \ | python3 -m json.tool | grep -E (process_key|form_key|version|status)这段脚本的作用是拉取某个流程定义的详情并筛选出关键字段。逻辑说明process_key 是流程在系统里的唯一标识form_key 是绑定的表单模型标识version 是当前发布的版本号status 表示是否启用。日常巡检时重点看 form_key 是否指向预期表单、status 是否为启用以及 version 是否符合预期版本。参数说明token 需要在管理后台生成每个管理员账号的 token 权限范围不同建议用一个只读权限的账号做检查避免误操作。4. 流程节点上的高频参数条件分支、会签规则与超时处理4.1 条件分支表达式怎么写才不容易误判条件分支是流程表单里配置量最大的部分也是问题最多的地方。先列一个最常踩的坑数值比较的类型不一致。表单里“请假天数”明明是一个数字字段但条件表达式里如果用的是字符串比较原本“大于 3”的判断会变成按字典序比较结果就是 10 天被判定为小于 3 天流程走到错误的分支。正确的做法是配置条件时先确认字段的数据类型再选择对应的比较操作符。数字字段用“大于”“小于”“介于”下拉框和单选用“等于”“包含”文本字段尽量少用或配合精确匹配。多条件组合时要注意逻辑关系是“且”还是“或”配置界面里通常用分组来区分一个分组内是“且”不同分组之间是“或”。条件表达式的边界值也需要单独确认。比如“请假天数大于等于 3 进入总监审批否则经理审批”要确认等于 3 时走哪条路。这类边界场景业务方通常不会主动说但配置时如果不定清楚就会出现“为什么 3 天的假要走总监审批”这类反馈。我习惯每配置一个条件分支就把边界值列出来找业务方确认一次成本最低效果最好。4.2 会签、或签与票数规则比例和顺序的取舍会签和或签是并行的常见形态。会签指所有审批人都要同意才通过或签指一人同意即可通过。在流程表单里会签支持按比例或按人数设定通过线。这里要区分两个子系统节点上配置的是“谁会参与”规则里配置的是“几个人/多少比例同意算通过”。经验值是人数多于 5 人时不要用 100% 会签否则任何一个审批人长时间不处理整个流程就卡死了。我见过一个案例某公司财务审批节点配了 6 个审批人 100% 会签其中一个人休长假没设置代理人所有报销单全部堵在那个节点最后运维同事手动挂起了好几条实例才把流程恢复。所以会签规则我会推荐两个选项要么减少参与人数要么把通过比例调低并配合自动跳过。或签的场景里要注意审批顺序。配置了按顺序或签第一个审批人拒绝后流程是否直接终止取决于节点设置。有的业务要求所有或签人都处理完有的只需要第一个同意的人处理。这两种需求对应的配置是不同的配置前一定要向业务方确认“第一个同意后其他人还看不看得到”。4.3 超时、催办与自动跳过参数怎么设不扰民超时和催办是管理员最容易“配过头”的地方。催办太频繁审批人一天收十几条站内信会直接把通知屏蔽催办太少流程又容易积压。常用的参数是一些可调的值我按常见的生产环境配置整理成表你可以按业务紧迫度调整参数项常见取值适用场景注意事项节点超时时间24/48/72 小时日常审批类节点超时动作要区分“催办”和“自动通过”催办频率每 8 小时一次业务反馈处理慢的节点超过 2 次未处理需升级到上级节点自动跳过条件金额小于 500 元低风险审批跳过前要留审计日志超时自动通过标记开启/关闭急单场景涉及合规的单据不建议开启代理人配置有效期7/30 天人员休假场景到期后提醒重新设置超时动作有两种催办和自动处理。自动处理又分自动通过和自动跳转。区别很大——自动通过代表节点审批人不需要操作单据直接放行自动跳转则是把单据转到下一节点。财务、法务这类合规节点我强烈建议不要启用自动通过最多自动跳转加超时提醒。请注意不是所有版本都支持全部动作配置前先确认你自己环境里的超时策略选项范围。我还会给每个超时规则加一条兜底超过两次催办仍未处理时给该审批人的上级发一封提醒。这个配置能在一定程度上防止“流程没死但卡在了一个人手里”的情况出现。5. 流程表单配置的常见坑与排查思路现象、原因、解决5.1 表单改了字段流程表单里选不到新字段现象管理员在表单模型里新增了一个“费用归属部门”字段保存并发布后进流程设计器定位到某个审批节点字段权限列表里看不到这个新字段。原因表单模型虽然发布了新版本但流程定义里引用的仍是表单的旧版本快照。流程定义不会自动跟随表单升级需要手动在流程定义中重新选择表单版本或者触发一次流程定义的版本刷新。解决进入流程定义管理把当前流程定义的表单版本切换到新发布版本然后重新发布流程。需要注意的是这个操作只影响之后发起的实例已经发起的单据仍然使用旧字段。如果业务方要求存量单据也能填新字段只能说明流程规则本身变了建议让存量单据按原规则走完。提示每次改完表单后建议立刻检查流程定义的绑定版本不要攒着一起发布否则排查“哪个版本里没有这个字段”会很费劲。5.2 发起人提交了单据但自己看不到待办或已办现象用户反馈“我提交的单据在已办里查不到”管理员查流程实例发现单据确实存在状态也是审批中。原因这个通常不是流程问题而是权限数据范围问题。流程表单里的列表数据权限和流程流转是两套体系前者控制“谁能看见哪些单据”后者控制“流程怎么走”。只配了流程节点权限没给发起人配置针对自己发起单据的列表查看权限就会出现单据存在但用户看不到的情况。解决在权限配置里给发起人角色增加数据范围常见配置是“本人发起的单据”可见或者按部门、按表单维度授权。这里有一个隐藏点管理员后台通常能看到所有实例所以这个问题在管理员自测时不会暴露一定要用普通员工账号做一次全流程验证。5.3 条件分支总是走到错误的路径现象例如请假天数大于等于 7 天走总监审批但实际 9 天的单子走的是经理审批。原因最常见的是字段类型不匹配导致的比较规则错位。数字字段被当成字符串比较时“9”小于“7”的判断在某些字典序规则下成立另一个常见原因是条件里引用的表单字段是旧版本页面上看到的是新字段实际判断用的还是旧数据的值。解决先检查条件表达式中字段的数据类型把数字类条件改成对应的数字比较操作符再确认流程定义里引用的表单版本。排掉这两个因素后如果仍走错分支可以在流程实例里打开“条件命中日志”查看每个节点连线的命中结果对比实际字段值做进一步定位。5.4 明细表数据在审批页不显示或显示不全现象报销单主表字段审批人能看到但费用明细一行都显示不出来或者只显示第一行。原因明细表在主流程表单里通常是以子表形式存在的审批节点的字段显示配置里如果漏掉了明细子表字段或者字段权限里把明细设为只读且前端渲染未兼容就会表现为“看不见”。解决检查审批节点绑定的表单版本里是否包含明细子表确认节点字段配置中明细表的显隐和读写权限。部分版本要求明细表在审批页以“表格只读组件”方式挂载而不是普通的字段平铺这个差异在跨版本升级后尤其常见。如果升级后出现的显示异常优先对比升级前和升级后的表单渲染兼容模式。5.5 流程实例发起了但发起时表单在关键位置显示空白现象用户发起流程时表单页能打开但其中某个区域比如会签意见区、附件上传区是空白刷新后偶尔能恢复。原因这类 zhengzhuang 多为浏览器兼容或前端资源加载问题流程表单依赖的渲染组件初始化失败。常见诱因是组织内的浏览器版本过旧或系统升级后前端静态资源缓存未刷新个别用户本地缓存了旧版 JS 文件。解决先让用户在浏览器无痕模式或强制刷新下重试如果能恢复基本排除服务器端配置。再确认办公电脑浏览器版本是不是在系统支持列表内不在的话升级或换用支持的浏览器。这里我建议管理员自己也定期换浏览器和账号验证别总用自己的管理员账号测因为管理员的交互链路和普通用户不完全一样并不能代表最终体验。6. 流程表单的进阶用法数据联动与脚本回调处理复杂业务6.1 字段级联与人员联动把审批人算出来流程表单里比较实用的进阶能力是字段级联。典型场景是“部门选完之后自动带出部门负责人”或者“项目类型选完之后自动填充流程主题”。级联配置的原理是基于表单字段间的映射关系常见实现方式是配置一个数据源然后在字段上挂联动规则。联动配置里最需要注意的是“级联字段触发时机”。有的联动是发起人选择后即时触发有的是表单提交时触发两者的体验差异很大。即时触发适合部门/人员联动实时反馈提交时触发适合计算类字段比如根据明细金额汇总总计。如果业务上要求发起人看到实时汇总务必选择即时触发并确认联动字段的计算性能。人员联动还有一个实用变体是“按表单字段值找审批人”。例如“区域”字段选“华东”审批人自动匹配华东区经理。这个配置把原来在流程节点上写死的人员改成了动态解析流程复用性大增。但要注意人员联动字段必须有兜底——当匹配不到审批人时流程是挂到管理员还是退回发起人两条路都要提前配上避免实例处在“无审批人”的悬浮状态。6.2 提交前校验与回写用脚本补全标准配置覆盖不到的部分标准配置能覆盖大多数场景但总有零星需求是 UI 配置做不了的。比如提交报销单时检测“本次报销金额 本月已报销金额”是否超出预算上限或者审批通过后把审批人、审批时间回写到主表字段。这类需求在流程表单里通常用脚本回调来实现。以下是一个提交前校验的脚本思路不同版本的实现位置不同这里用通用写法说明逻辑// 提交前校验脚本示例检查本月累计报销是否超限 // 假设表单字段applyAmount(本次申请金额)、applicant(申请人) // 外部数据源通过上下文对象 ctx 获取 function validateBeforeSubmit(ctx) { // 1. 从上下文中取出本次申请金额注意类型转换 const currentAmount Number(ctx.form.get(applyAmount)) || 0; // 2. 调用查询接口获取该申请人本月的累计报销金额 // summaryApi 为管理端提供的汇总查询能力返回 { total: ... } const monthSummary ctx.api.call(summaryApi, { applicant: ctx.form.get(applicant), month: new Date().getMonth() 1 }); // 3. 判断是否超限累计 本次 预算上限 const limit Number(ctx.config.get(monthlyLimit)) || 5000; if (monthSummary.total currentAmount limit) { // 阻断提交返回错误提示 return { pass: false, message: 本月累计报销已超预算上限请联系财务确认 }; } return { pass: true }; }逻辑说明脚本在表单提交前触发先从表单上下文取出本次申请金额再通过汇总接口查询申请人当月已报销总额最后和预算上限做比较超限则阻断提交并返回提示。参数说明ctx.form.get() 可用来自动获取当前表单的字段值ctx.api.call() 调用外部汇总能力ctx.config.get() 读取管理员预先配置的常量。不同实施环境里这三个对象的命名不一定相同但思路一致。这个脚本的价值在于把“金额超限”这件事从人工判断变成系统拦截省掉财务大量沟通成本。审批通过后回写是另一个高频脚本场景。常见做法是流程节点的“通过”动作上挂一段脚本审批人点击同意后把审批人的姓名、审批时间写入表单里的“最后审批人”“最后审批时间”字段。这要求在表单里预留这几个隐藏字段并在网格配置里把它们设为可写。回写脚本的返回值只是确认写成功不要在回写脚本里再调审批动作避免逻辑嵌套把自己绕晕。6.3 把脚本和配置放一起的价值从能用走向好用流程表单走到脚本这一步说明你已经从“照着手册配”变成了“按业务需求设计流程”。我个人的习惯是能用标准配置解决的绝不上脚本因为脚本意味着维护成本、权限风险、以及后续升级时的兼容性问题但标准配置确实覆盖不了的场景脚本是最后一公里的答案。我把这条边界总结成一句经验先画流程再配表单先跑通标准功能再加脚本增强最后一定要用一个真实业务账号从头到尾走一遍完整流程。前几年有次我深夜收到业务方电话说新流程发不出去排查半天发现是脚本里引用了一个已删除的字段名——这种问题自己测一遍就能提前拦住不需要躺着让人催着查。希望这些习惯和坑位整理能帮到你少熬几个深夜。本文还有配套的精品资源点击获取
绿色便携版：离线专业术语查取引擎)
