Jira 工作流迁移后审批流转不生效，通常集中在四类原因：工作流与审批配置未完整对应、审批人字段或用户组映射失效、权限方案限制审批人操作、触发与自动化规则未随迁移重建。排查时建议从“审批节点是否被触发”入手，再核对转换条件与审批人解析，最后验证权限与通知，用证据逐层排除，避免直接重配整条工作流。
要点总览（TL;DR）
- 审批流转不生效先拆症状：审批节点不出现、无人可审、审批人无法提交、提交后状态不推进、通知未发出，不同表现指向不同排查层。
- 常见原因分四类：工作流与审批配置映射缺失或指向错误、审批人字段与用户组映射失效、权限方案限制审批人操作、触发与自动化规则未随迁移重建。
- 判断配置问题还是人员权限问题可用对照法：管理员能推进而业务审批人不能，倾向人员或权限；两者都不能推进，倾向转换条件、校验或后处理配置。
- 排查按审批节点触发、转换条件与审批人解析、权限覆盖、通知与自动化的顺序推进，修改生产工作流前备份并在测试项目验证，设定回滚停止点。
- 修复后用一条完整审批链路做端到端验证，并把工作流配置核对、角色与审批人对应、含审批工作流试运行纳入迁移验收清单。
先界定症状：审批流转不生效有哪几种表现
“审批流转不生效”是一个笼统描述，不同表现指向的原因差别很大。排查前先把用户反馈转成可观察的现象，记录出现问题的具体工作项、操作人和操作时间，才能确定从哪一层开始查。
常见表现可以归为以下几类：
| 症状表现 | 用户看到的现象 | 初步指向的排查层 |
|---|---|---|
| 审批节点不出现 | 工作项进入某状态后，审批环节没有生成，直接进入下一状态或停滞 | 工作流转换配置、审批节点绑定 |
| 审批节点出现但无人可审 | 审批列表为空，或显示“无审批人” | 审批人字段解析、用户与用户组映射 |
| 审批人无法提交 | 审批人能看到待办，但提交按钮不可用或提交报错 | 转换条件、校验规则、权限方案 |
| 提交后状态不推进 | 审批已通过，工作项状态未变化或停留在原状态 | 后处理函数、转换目标状态映射 |
| 通知未发出 | 审批已流转，但相关人未收到通知 | 通知方案、邮件服务器、自动化规则 |
确定表现后，还要记录影响范围：问题只出现在一条工作流还是多条工作流，只影响一个项目还是多个项目，迁移前是否正常。范围信息能显著缩小假设空间——单条工作流失效更可能是该工作流的转换或审批配置问题，多项目同时失效则更可能与全局权限方案、用户目录或自动化服务有关。
最后记录一条可复现路径：从哪个状态发起、经过哪个转换、期望由谁审批、实际停在哪一步。这条路径是后续验证和修复后回归测试的基准。
原因假设与排除证据：审批流转失效的常见来源
把可能原因分成配置映射、人员映射、权限与条件、触发与自动化四类，每类都给出可观察的验证证据。排查时按“先配置、再人员、后权限、最后自动化”的顺序逐项证实或排除，避免同时改动多处导致无法判断哪项修复起了作用。
配置映射类：状态、转换、条件、校验、后处理缺失或指向错误
迁移过程中，工作流的状态、转换、条件、校验和后处理函数需要逐项对应。常见问题是某个转换在迁移后丢失了条件或校验配置，或者后处理函数指向了不存在的字段、状态或用户。验证证据包括：在工作流配置中打开出问题的转换，核对条件、校验和后处理是否与迁移前一致；检查转换的目标状态是否存在且名称对应；用管理员账号在测试项目手动执行同一转换，观察是否报错或静默失败。如果管理员也无法推进，配置映射问题的可能性明显上升。
人员映射类：审批人字段、用户、用户组、角色解析为空
审批节点依赖审批人字段或角色来解析具体审批人。迁移后如果字段值丢失、用户账号未对应、用户组或项目角色成员为空，审批人解析结果就是空集，表现为“无人可审”。验证证据包括：查看该工作项的审批人字段当前值；在用户与用户组管理中确认相关账号和组成员是否存在；检查项目角色中是否包含预期审批人。一个有效的对照方法是：把审批人临时指定为一个确定存在的管理员账号，若审批节点随即可以正常出现和提交，人员映射问题的可能性较高。
权限与条件类：审批人看不到或无法执行转换
即使审批人解析正确，权限方案也可能让审批人看不到工作项、看不到转换按钮或无法提交。迁移后权限方案与项目角色的对应关系容易错位。验证证据包括：用审批人账号登录，确认其能否打开该工作项、能否看到对应转换；对比管理员账号与审批人账号在同一工作项上的可见操作差异；检查权限方案中该转换的执行权限授予了哪些角色或用户组。管理员可推进而业务审批人不能推进，是权限或人员问题的典型信号。
触发与自动化类：触发器、自动化规则、监听器未重建
如果审批流转依赖定时触发、字段变更触发或自动化规则（例如状态变更后自动指派审批人、自动发送通知），这些规则在迁移后可能未重建或未启用。验证证据包括：检查自动化规则的启用状态和触发条件；查看规则执行记录中是否有失败或未命中；确认通知方案是否绑定了正确的项目和事件。通知未发出但状态正常推进时，优先查这一层。
原因假设与验证证据对照
| 原因类别 | 典型现象 | 关键验证证据 | 建议排查顺序 |
|---|---|---|---|
| 配置映射 | 审批节点不出现、提交后状态不推进 | 转换条件/校验/后处理与迁移前比对；管理员账号复现 | 第 1 步 |
| 人员映射 | 审批节点出现但无人可审 | 审批人字段值、用户与用户组、项目角色成员 | 第 2 步 |
| 权限与条件 | 审批人看不到或无法提交 | 审批人账号与管理员账号的操作差异；权限方案授权范围 | 第 3 步 |
| 触发与自动化 | 通知未发出、审批人未自动指派 | 自动化规则启用状态与执行记录；通知方案绑定 | 第 4 步 |
判断配置映射问题还是人员/权限问题，可以用一个简单对照：同一工作流在测试项目中分别用管理员账号和业务审批人账号走一遍。管理员能推进而审批人不能，倾向人员或权限问题；两者都不能推进，倾向转换条件、校验或后处理配置问题。
按顺序处置：从审批节点到权限的排查步骤
排查按“审批节点是否触发—转换条件与审批人解析—权限覆盖—通知与自动化”的顺序推进，每一步都留下证据再进入下一步。涉及生产工作流的修改，先备份当前配置，在测试项目复现并验证后再发布。
- 验证审批节点是否被触发。查看工作流日志或审计记录，确认工作项进入审批状态时是否生成了审批任务、由哪个转换触发、是否有报错。若日志显示转换执行失败，直接定位到该转换的配置；若日志显示转换成功但无审批任务，检查审批节点是否绑定到该转换。
- 核对转换条件、校验与审批人字段解析结果。打开出问题的转换，逐项比对条件、校验和后处理配置与迁移前是否一致；查看审批人字段的实际解析结果，确认解析出的是具体用户而非空值。此步可在测试项目用相同数据复现，避免在生产环境反复试错。
- 检查权限方案与项目角色是否覆盖审批人。用审批人账号验证其能否看到工作项和转换按钮；核对权限方案中转换执行权限的授予对象，确认项目角色成员包含预期审批人。若权限方案在迁移后整体重建，重点检查角色与用户组的对应关系。
- 检查通知与自动化规则是否重建。确认相关自动化规则处于启用状态、触发条件与迁移前一致，查看规则执行记录；核对通知方案是否绑定到正确项目和事件。通知问题通常不影响状态推进，可放在最后处理。
风险边界需要提前明确：修改生产工作流前备份当前配置和权限方案；所有配置变更先在测试项目验证；为每次变更设定回滚停止点——如果修改后审批流转仍未恢复，或出现新的状态异常，立即回滚到备份配置，不在生产环境连续叠加改动。审批人字段和权限方案的调整影响面较大，建议在业务低峰期执行并通知相关审批人。
如果迁移目标平台是 ONES，其 Jira 迁移方案覆盖项目、工作项、状态、字段、流程、附件和历史记录，并支持迁移问题类型、工作流、字段配置、权限配置以及用户和用户组。排查时可对照迁移范围逐项核对：工作流与权限配置是否按预期迁入、用户组与审批人字段的对应关系是否完整。对于原 Jira 环境依赖插件实现的审批或自动化场景，迁移前需要逐项评估功能匹配情况，迁移后重点验证这些场景是否已由对应能力承接。
验证恢复与预防复发
修复后不要只验证出问题的那一步，而要用一条完整审批链路做端到端验证，确认发起、审批、状态推进和通知四个环节都正常。
端到端验证清单：
- 用普通业务账号发起一条测试工作项，确认能进入审批状态并生成审批任务；
- 用审批人账号登录，确认能看到待办、能打开工作项并提交审批；
- 审批通过后确认工作项状态按预期推进到目标状态，无停滞或跳转错误；
- 确认发起人、审批人及相关角色收到对应通知；
- 用管理员账号复核同一链路，排除仅管理员可用的配置掩盖问题。
验证通过后，整理迁移前后的工作流与审批配置差异清单，标注本次修复涉及的转换、条件、审批人字段和权限项，作为后续变更的基线。差异清单同时用于识别尚未验证的其他工作流，避免同类问题在别的项目中重复出现。
预防复发方面，建议在迁移流程中固定三项检查：迁移完成后逐条工作流核对状态、转换、条件、校验和后处理是否完整；核对用户、用户组、项目角色与审批人字段的对应关系；在测试项目对每条含审批的工作流做一次试运行，通过后再切换生产使用。把这些检查项纳入迁移验收清单，审批流转问题就能在上线前被发现，而不是等业务提交时才暴露。
常见问题
迁移后只有部分项目的审批流转失效，应该先查哪里？
先确认失效项目与正常项目在配置上的差异。重点看三处：这些项目使用的工作流是否为迁移后单独调整过的版本；项目角色成员与审批人字段的对应关系是否完整；权限方案是否与其他项目不同。单项目或少数项目失效，通常指向该项目的角色成员、权限方案或工作流绑定关系，而不是全局用户目录问题。可以选一个正常项目作为对照，逐项比对配置后再动手修改。
审批人字段显示有值，但审批列表仍然为空，可能是什么原因？
字段有值不等于能解析出有效审批人。可能的情况包括：字段中保存的是迁移前的用户标识，迁移后未对应到现有账号；字段值是用户组或角色，而该组或角色在迁移后成员为空；审批节点读取的是另一个审批人字段，与页面上显示的不是同一个。排查时打开审批节点的审批人配置，确认它实际读取哪个字段或角色，再用该字段的值去用户管理中逐一核对账号是否存在、是否启用。
修复审批流转时，能否直接在生产环境修改工作流？
建议避免直接在生产工作流上反复试错。较稳妥的做法是先备份当前工作流、权限方案和相关自动化规则配置，在测试项目用相同数据复现问题并验证修改效果，确认审批链路完整走通后再发布到生产。如果业务紧急必须在生产调整，也应一次只改一处并记录变更内容，同时设定回滚停止点：修改后审批仍未恢复或出现新的状态异常，立即回滚到备份配置，不在生产环境连续叠加改动。
原 Jira 环境用插件实现的审批，迁移后需要额外注意什么？
插件实现的审批逻辑通常不会随标准配置一起迁移，需要在迁移前梳理实际使用的插件和对应场景，再评估目标平台用什么能力承接。以 ONES 为例，其迁移方案建议先梳理插件使用情况，再通过 ONES Project、Wiki、TestCase、流程自动化和开放能力做功能匹配，企业已有的定制场景仍需逐项评估，避免假设所有插件都能一一对应。迁移后应把这类场景列为重点验证对象，确认审批触发、审批人指派和状态推进都由承接能力正常完成。
审批流转恢复后，如何确认没有遗漏其他工作流？
把本次修复涉及的转换、条件、审批人字段和权限项整理成差异清单，作为基线；再对照迁移范围，逐条检查其他含审批的工作流是否存在同类配置缺失。检查可以按工作流逐条进行：核对状态与转换是否完整、条件与校验是否与迁移前一致、审批人字段能否解析出具体用户、项目角色是否覆盖审批人。对每条含审批的工作流在测试项目做一次试运行，通过后再投入生产使用，能把同类问题在上线前发现。
