本章适用于工作流设计、发起、任务处理和运行异常。先根据现象定位,再检查对应配置;修正后用一笔测试业务确认结果。
保存或发布失败:查看设计器底部的校验结果,点击提示定位配置。
点击发起后没有流程:检查已发布版本、启动参数、业务键和操作权限。
有待办但页面没有内容:检查任务跳转参数与 UX 的取值、查询方式。
点击完成后数据不对:分别检查业务数据保存、任务回传参数和节点数据映射。
运行到某节点报错:在流程监控中定位该实例、节点和作业信息,再按下文处理。
反馈问题时,请提供发生时间、工作流名称、流程实例 ID、任务实例 ID(如有)、报错节点和完整错误信息。日志中的 Cookie、Token、业务敏感数据应先脱敏。
点击底部校验项,按提示检查节点、连线、必填参数和引用元素。修改后重新保存或发布;确认发布成功后,再从 UX 发起一笔新流程验证。保存设计稿并不等于更新已发布的流程版本。
按传递顺序检查:
工作流的用户任务是否启用待办跳转界面,且关联了正确的 UX。
跳转参数名称是否与 UX 中 $urlQuery 的属性名一致,注意大小写。
业务参数是否来自有值的启动参数或全局变量。
UX 数据源的查询条件是否使用该参数,是否有权读取这条业务记录。
是否从待办的实际任务打开页面。直接在编辑器预览时,通常没有这条任务的 URL 参数。
例如工作流传 contract = wfi$contract_id,UX 就读取 $urlQuery.contract;参数名不会自动改成 contract_id。配置步骤见 工作流打开 UX 与传参。
业务记录和任务是两种对象,需要分别定位。业务编号不能填入“任务实例 ID”;任务实例 ID 来自用户任务的 acp$task_id,流程实例 ID 来自 wfp$proc_id。
检查控件查询方式、传入 ID、当前用户与任务关系、任务是否已完成,以及是否开启了相应的后备查询。一个流程可能有多条任务,不能用流程 ID 代替任务 ID。详见 任务处理与结果回传。
UX“完成任务所需参数”进入当前任务的 acr$extra_res。例如回传参数名为 approved_amount,在当前节点读取 acr$extra_res.approved_amount,再通过数据映射写入全局变量 wfv$approved_amount,后续节点读取全局变量。
同时核对参数名、空值和类型。保存业务表单不会自动写入工作流变量;任务完成也不会自动保存业务表单。两者需要分别配置。
工作流有版本。先核对目标流程实例实际使用的版本,再检查本次修改是否已发布。用一笔新实例验证新配置;不要仅凭旧待办的效果判断新版本未生效。详见 流程发布与流程管理。
启用业务键唯一后,检查用于组合业务键的启动参数,以及同一业务是否已有进行中的实例。重复点击、按钮事件重复绑定也可能重复发起。业务编号、流程实例 ID 和业务键不一定相同,不要为绕开提示随意改变业务键。详见 从 UX 发起流程。
节点作业信息包含“领域动作”“状态迁移异常”或 approval status。

查看财务模型节点实际传入的业务主键和事件。
查出这笔业务当前的状态,检查是否为空。
在状态迁移配置中,确认“当前状态 + 事件”存在有效组合。
根据业务事实修正数据或参数,再验证对应状态迁移。

检查实际接收人、通知模板参数和节点完成规则。邮件接收人的邮箱为空时,作业信息可能出现 "toEmail":"contact-empty"。


如果业务要求所有人收到邮件,应补齐用户邮箱,并在使用 SystemUser 对象的场景执行“平台用户同步”,核对对象中的 email 已更新。

“全部成功”要求全部接收人发送成功;只有业务允许部分接收人成功就继续时,才选择“部分成功”。同时检查模板入参是否存在 null,按模板要求补齐,不要用更改完成规则掩盖必达通知失败。
异步调用成功表示脚本已被调起,不表示业务执行完成。需要等待结果的场景,应按 PY 脚本 和 最佳实践 配置“异步调用 + 等待消息”。核对等待节点的消息、目标流程实例和回传参数。
这是一类通用提示,不能仅凭这四个字确定原因。记录触发步骤、时间、实例 ID 和完整响应;结合流程作业信息与对应服务日志定位。若刚升级过环境,还需由管理员核对前后端组件版本和接口是否配套。
功能咨询请说明“谁在什么页面做什么操作,期望看到什么结果”;方案咨询请补充流程图、参与角色、业务数据来源和例外情况。先用本章及 UX 配合使用 缩小问题,再提交脱敏资料。
回到顶部
咨询热线
