Office 365 SharePoint 2013工作流突发故障求助

遇到过好几次类似的SPD工作流突然罢工的情况，结合你描述的“运行一年后突发故障、测试站也同步失效”的场景，给你列几个优先级最高的排查方向：

• 检查租户的基本认证状态
  Office 365近年一直在逐步禁用基本认证，很多租户会在不知不觉中被强制开启这个限制。SPD 2013工作流里的HttpWebService活动默认可能依赖基本认证来调用API，如果你的租户最近刚好禁用了基本认证，就会导致请求反复重试失败。
  可以用PowerShell登录租户检查：

  Connect-MsolService
  Get-MsolDomainFederationSettings -DomainName "yourdomain.com"
  

  或者直接去Microsoft 365管理中心的设置 > 集成应用 > 认证方法里查看是否禁用了基本认证。

• 验证工作流使用的账户权限
  运行一年后突然失效，大概率是权限发生了变更：比如工作流关联的服务账户（或者触发工作流的用户账户）被移除了列表的管理权限，或者失去了调用SharePoint API的权限。
  可以测试用该账户手动修改列表项权限，如果手动都无法操作，那就是权限问题无疑了。

• 手动测试HttpWebService调用是否正常
  把工作流里调用的Web服务请求复制出来，用Postman或者REST Client工具手动发送（用和工作流相同的账户认证），看是否能成功修改权限：

  • 如果手动调用也失败，说明问题出在API本身、权限或者租户配置上；
  • 如果手动调用成功，那就要检查工作流里的请求参数是否有误（比如列表名称、项ID拼写错误），或者工作流的认证配置是否出了问题。

• 检查租户最近的服务更新
  微软会定期给SharePoint Online推送更新，某些更新可能会影响SPD 2013工作流的兼容性。去Microsoft 365管理中心的消息中心，看看最近是否有关于工作流、Web服务或者权限管理的变更公告，这往往是这类“突然失效”问题的根源。

• 排查工作流的超时与重试配置
  报错里的“Retrying last request”说明工作流一直在重试失败的请求，可能是请求超时导致的。比如列表项关联的权限组过多，修改权限操作耗时超过了工作流的默认超时时间。可以尝试修改工作流活动的超时设置，或者测试修改一个权限简单的列表项，看是否能成功。

另外提一句：SPD 2013工作流已经被微软标记为淘汰技术，长期来看建议迁移到Power Automate，避免后续再出现这类兼容性问题。

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