在宜搭（YiDA）或类似的低代码流程引擎中，遇到“退回后从当前节点审批无效”以及“相邻节点自动审批失效”的问题，通常是因为流程引擎的状态机逻辑与自定义的节点属性设置发生了冲突，或者是退回动作触发了新的流程实例快照，导致原有的“自动通过”上下文丢失。
以下是针对这两个问题的深度排查步骤和解决方案：
问题一：退回时设置“从当前节点审批”无效
现象描述：用户执行退回操作，选择了“退回到上一节点”或“指定节点”，并勾选了“从当前节点（即被退回到的节点）开始审批”，但实际流程却直接从被退回节点的下一个节点继续流转，或者卡在了发起人处。
原因分析：
节点属性优先级冲突：目标节点（被退回的节点）可能配置了“自动审批”或“跳过”规则，其优先级高于退回时的指令。
退回动作的定义误解：宜搭中标准的“退回”动作通常是将单据状态回滚到历史节点，默认行为是等待该节点的处理人重新提交。所谓的“从当前节点审批”通常是指“是否需要该节点处理人再次点击同意”。如果该节点配置了自动通过，它就不会等待人工干预。
分支条件判断：退回后重新进入该节点时，流程可能会重新计算出口分支条件。如果条件满足直接通向下一节点，就会看起来像“跳过了审批”。
解决方案：
1. 检查目标节点的“自动审批”设置
进入流程设计器，点击被退回的那个节点（例如：经理审批节点）。
检查右侧属性面板中的 “自动审批” 或 “高级设置”。
关键点：确认是否开启了“满足条件自动通过”。如果开启了，退回后只要数据没变，条件依然满足，系统会自动秒过，导致看起来像“从当前节点审批”无效（因为它确实审批了，只是自动完成的）。
修正：如果希望退回后必须人工再次确认，请关闭该节点的自动审批功能，或者在自动审批条件中增加排除逻辑（例如：
is_rollback == true时不自动通过，但这需要业务字段支持）。
2. 使用“撤回”而非“退回”（场景匹配）
如果您的意图是让发起人修改后，中间经过的节点不需要再审，直接跳到之前卡住的地方，这通常应该用 “撤回” (Recall) 功能，而不是“退回” (Return/Reject)。
退回 = 否定当前结果，流程回滚，通常需要重走流程。
撤回 = 撤销当前操作，流程回到上一步，修改后提交通常可跳过已审批节点（取决于配置）。
操作：检查流程全局设置，确认是否启用了“允许撤回”，并指导用户使用撤回。
3. 检查“退回策略”配置
在发起退回操作的节点（例如：老板审批节点）的属性中，查看“退回设置”。
确认退回的目标节点选择是否正确。
部分版本中，退回后的行为由流程引擎内核决定，无法强制“从当前节点审批”如果该节点本身被配置为“无需操作”。请确保目标节点是一个人工审批节点，且处理人不为空。
问题二：回退后，相邻节点自动审批功能失效
现象描述：正常流转时，节点 A 审批后，节点 B 会自动通过（或自动流转到 C）。但如果是从节点 C 退回到节点 A，节点 A 重新审批通过后，节点 B 不再自动通过，而是挂起等待人工处理。
原因分析：
流程实例上下文重置：当流程发生“退回”时，引擎往往会创建一个新的“审批轮次”或重置部分运行时上下文。某些基于“首次进入”或“特定变量状态”的自动审批逻辑，在第二轮次中可能因为变量未更新而判定失败。
自动审批的触发时机：自动审批通常发生在节点进入时 (OnEnter)。退回重走后，如果数据没有发生变化，而自动审批的条件依赖于“数据变更”或“特定标记”，则条件不满足。
历史审批记录干扰：引擎检测到该节点在上一轮次已审批通过，为了防止死循环或逻辑错误，某些配置下会强制要求人工二次确认，从而覆盖自动审批规则。
解决方案：
1. 优化自动审批的条件逻辑（推荐）
不要仅依赖默认的空条件，而是显式定义条件。
进入相邻节点（节点 B） 的自动审批设置。
检查条件公式。建议使用明确的业务字段，而不是隐式的流程状态。
错误示例：仅依赖系统隐含状态。
正确示例：
金额 < 5000或类型 == '普通报销'。关键技巧：如果是因为退回导致上下文丢失，可以在节点 A（退回目标节点） 的“节点保存/提交”事件中，通过业务规则（JS）设置一个临时标记字段（如
force_auto_pass = 1）。然后在节点 B 的自动审批条件中加入OR force_auto_pass == 1。
2. 检查“重复审批”设置
在流程设计的 全局设置 或 节点属性 中，查找类似 “节点重复审批策略” 的选项。
有些配置项为：“若节点已审批过，再次进入时是否自动跳过？”
如果设置为“否”，则退回重走时必须人工点。
如果设置为“是”，通常会触发自动通过。请尝试切换此选项测试。
3. 使用“业务关联规则”替代节点内自动审批
如果节点内的自动审批不稳定，可以使用宜搭的 “业务关联规则” (Integration Rules) 或 “服务端事件” 来模拟自动审批。
逻辑：监听表单的“更新”事件。
代码逻辑：
// 伪代码示例 if (event.nodeId == 'Node_A' && event.action == 'APPROVE') { // 检查是否满足自动通过 Node_B 的条件 if (formData.amount < 1000 || formData.is_rollback_retry == true) { // 调用宜搭 API 自动审批 Node_B await this.utils.approveNode('Node_B', { comment: '系统自动通过' }); } }这种方法最可控，完全绕过引擎自带的自动审批机制，无论是否退回都能生效。
综合排查清单 (Checklist)
请按顺序执行以下操作：
清理缓存发布：修改任何流程配置后，务必点击 “发布” 生效。有时候浏览器缓存会导致旧逻辑生效。
验证节点类型：确认“相邻节点”确实是审批节点，而不是抄送节点或填充节点（这些节点的行为逻辑不同）。
查看运行日志：
进入宜搭后台 -> 应用管理 -> 流程实例 -> 找到出错的实例 -> 点击 “运行日志” 或 “审批记录”。
观察退回后，相邻节点的状态是“自动通过”还是“待处理”。
如果是“待处理”，查看是否有系统注释提示“不满足自动审批条件”。
简化测试：
新建一个最简单的测试表单，只包含 A -> B -> C 三个节点。
设置 B 为无条件自动审批。
测试 A->B(自动)->C，然后 C 退回 A，A 再提交，看 B 是否自动。
如果简单测试成功，说明原流程中存在复杂的分支条件或变量干扰；如果简单测试也失败，可能是平台特定版本的 Bug 或全局配置问题，建议提交工单给宜搭技术支持。
总结建议：
最稳妥的方案是不要过度依赖“退回”动作后的隐式自动逻辑。如果业务要求退回修改后特定节点免审，建议在退回前的节点通过 JS 脚本将数据标记为“免审状态”，或者在目标节点使用显式的业务规则（API 调用）来执行自动通过，这样能最大程度保证逻辑的稳定性。