7
votes

We recently migrated from MOSS 2007 to SP 2010 platform. We have this heavily-used SharePoint Designer workflow (500 and more instances per day) that uses InfoPath to submit data. It is basically a serial Approval workflow involving many approval levels. Post-migration almost 90% of our workflow runs end in "Error Occurred" state with the following description of the error:

The workflow could not update the item, possibly because one or more columns for the item require a different type of information.

There is no set pattern for the workflows that result in an error and restarting the workflow always resolves the issue.

  1. We have matched all columns/content type and there is no difference in MOSS 2007 and the new forms library

  2. Permission levels of Users are not changed

A lot of sites mention introducing a pause in the workflow before the update event, but I am skeptical in doing it. What could be the possible cause/solution to it? We cannot identify anything that is common or direct us to the root cause among these 90% failing workflows. Some of the workflow instance also result in an error:

the workflow could not update the item as it was checked out to another user.

5

5 Answers

5
votes

I've had the same issue in the past and the 1 minute delay resolved it. In my experience, the inconsistencies in terms of which items fail and which don't, had us looking down the path of a lock issue. It didn't make any sense otherwise. If we took one specific item in the list and tested against it, sometimes the workflow would run successfully and other times it would fail. Depending on the hardware we used, we'd get entirely different results with the same configuration.

Others with a similar issue report locking as the issue. http://social.technet.microsoft.com/Forums/en-US/sharepoint2010customization/thread/fc4e1073-d67f-449a-b443-e5805f5358c7

It appeared to me that maybe it was a locking/timing issue....it appeared the workflow kicked off and tried updating fields in the doc library item before the locks were released on the InfoPath form that created the item!

When you did the migration, was new hardware involved? Also factor in that SharePoint 2010 requires more power than 2007 ever did.

2
votes

The problem seems to be in fact related to attempt of changing the locked field. If you don't want to introduce 1 minute delay to your workflow before changing previously updated fields in your workflow (that should always work..) you may want to add Wait for Field Change in Current item action between updates of the same field. In some circumstances that is possible and worked quite well in may case.

0
votes

There may be many cause for the issue, for me it was related to user permissions:

workflow was creating an item in another list on behalf of the user and he was having only read permissions on that list, by giving contribute permissions on another list it worked.

-1
votes

Before assuming a locking/timing issue, ensure that your workflow isn't updating to the incorrect column type. In our case, we were trying to update a Person or Group field with invalid data.

-1
votes

If it is happening randomly, probably pretty safe to rule out permissions issue. I think I was able to solve my issue, and based on my testing - so far so good.

http://www.eveningblog.com/archive/sharepoint-2010-error-the-workflow-could-not-update-the-item/