Azure Logic Apps工作流随机断开，触发'WorkflowNotFound'错误求助

以下是针对该问题的排查和解决建议：

• 直接使用工作流资源ID而非名称配置连接
  GUI自动识别的工作流连接可能依赖名称匹配，当工作流有部署更新、版本变更或资源元数据变动时，名称解析可能失效。建议在连接配置中手动指定目标工作流的完整资源ID，格式为：

  /subscriptions/{你的订阅ID}/resourceGroups/{资源组名称}/providers/Microsoft.Logic/workflows/{目标工作流名称}
  

  避免依赖动态名称解析导致的找不到资源问题。

• 验证托管标识权限配置
  如果调用方工作流使用托管标识访问目标工作流，确保调用方的托管标识对目标工作流拥有Logic App Contributor或Logic App Operator权限，且权限范围直接覆盖目标工作流资源（而非仅资源组级）。权限配置不当可能导致身份验证令牌过期后无法重新获取授权，触发WorkflowNotFound错误。

• 检查工作流版本与状态
  确认你连接的是目标工作流的已发布稳定版本，而非临时的草稿版本或已归档的旧版本。如果使用了版本化部署，GUI可能默认选择旧版本，当旧版本被清理后就会出现找不到的情况。同时定期检查目标工作流是否被意外禁用或修改。

• 排查连接的令牌刷新机制
  Azure AD令牌默认有效期为1小时，正常情况下Logic Apps会自动刷新令牌。如果是自定义连接，检查是否启用了自动刷新配置。可以尝试删除现有连接重新创建，确保连接使用的身份验证方式支持自动令牌刷新。

• 查看Azure活动日志
  进入目标工作流的Azure资源页面，查看活动日志，筛选“删除”“更新”“禁用”等操作，确认是否有自动化脚本、Azure Policy或其他定时操作在约1小时后修改了工作流的状态或资源属性，导致工作流无法被识别。

• 改用HTTP触发直接调用
  绕过GUI的自动连接逻辑，在调用方工作流中添加HTTP动作，直接使用目标工作流的触发URL（从目标工作流的触发器页面复制）进行调用，验证是否还会出现断开问题。这种方式不依赖Logic Apps内部的连接解析，能排除连接配置本身的问题。

内容的提问来源于stack exchange，提问作者andre7455