我们最近从MOSS 2007迁移到SP 2010平台。我们有这个使用频繁的SharePoint Designer工作流程（每天500个或更多实例），它使用InfoPath提交数据。它基本上是一个涉及许多批准级别的系列批准工作流程。迁移后几乎90％的工作流程都以“发生错误”状态结束，并显示以下错误描述：
工作流无法更新项目，可能是因为项目的一个或多个列需要不同类型的信息。
导致错误的工作流没有设置模式，重新启动工作流始终可以解决问题。
许多网站都提到在更新事件之前在工作流中引入暂停，但我对此持怀疑态度。可能的原因/解决方案是什么？在这些90％失败的工作流程中，我们无法识别任何常见的东西或将我们引向根本原因。某些工作流实例也会导致错误：
工作流无法更新项目，因为它已签出给其他用户。
我过去遇到了同样的问题，1分钟的延迟解决了这个问题。根据我的经验，在哪些项目失败以及哪些项目失败方面存在不一致，让我们向下看了锁定问题的路径。否则它没有任何意义。如果我们在列表中选择了一个特定项目并对其进行了测试，则有时工作流程将成功运行，有时则会失败。根据我们使用的硬件，我们将使用相同的配置获得完全不同的结果。
有类似问题的其他人报告锁定问题。 http://social.technet.microsoft.com/Forums/en-US/sharepoint2010customization/thread/fc4e1073-d67f-449a-b443-e5805f5358c7
在我看来，这可能是一个锁定/计时问题....在创建项目的InfoPath表单上发布锁之前，工作流程似乎已启动并尝试更新doc库项目中的字段！
当您进行迁移时，是否涉及新硬件？此外，SharePoint 2010需要比2007年更强大的功能。
这个问题似乎与更改锁定字段的尝试有关。如果您不想在更改工作流中以前更新的字段（应始终有效）之前向工作流引入1分钟延迟，则可能需要在同一字段的更新之间添加当前项操作中的等待字段更改。在某些情况下，可能并且在可能的情况下工作得很好。
这个问题可能有很多原因，对我而言，它与用户权限有关：
工作流正在代表用户在另一个列表中创建一个项目，并且他只对该列表具有读取权限，方法是在其工作的另一个列表上提供贡献权限。
在假定锁定/计时问题之前，请确保您的工作流程未更新为不正确的列类型。在我们的例子中，我们尝试使用无效数据更新Person或Group字段。
如果它是随机发生的，可能非常安全地排除权限问题。我想我能够解决我的问题，并根据我的测试 - 到目前为止一切顺利。
http://www.eveningblog.com/archive/sharepoint-2010-error-the-workflow-could-not-update-the-item/