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

Question

We recently migrated from MOSS 2007 to SP 2010 platform. We have this heavily used SharePoint Designer workflow(500 and more instances per day). (uses infopath to submit data) It is basically an serial Approval workflow involving many approval levels. Post migration almost 90% of our workflow 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.

I have searched a lot of websites and msdn, tried possibly all solutions given, but none seems to work.There is no set pattern for the workflows that result in error and restarting the workflow always resolve the issue.

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

2. Permission levels of Users are not changed

A lot of sites mention introducing a pause in the workflow before 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 error, the workflow could not update the item as it was checked out to another user.

Any help would be highly appreciated.

Answer 1

I have experienced this error as well. The only solution we have come to was adding a one minute pause. I believe that it is something to do with the WF starting one task before the previous is finished. This sounds like Voodoo but it has worked every time in our environment. Sorry I cannot give you a better answer or theory. "The workflow could not update the item..." intermittent error involving Lookup Column in Designer WF

Answer 2

Make sure you don't have the "Enable Content Approval" option checked at the bottom of the workflow settings when your library/list doesn't even have Content Approval turned on. Having this option checked without the Content Approval feature in use will result in this error message.

Answer 3

I faced the same issue and resolved it using below approach, it occurs sometimes when people picker field has setting enabled for multiple users:

Creating/Updating People picker field value using SharePoint Designer workflow is different, or we cannot directly update the field value by another people picker field value.

Suppose we have 2 lists, List 1 has a people picker column "Manager", List 2 has a people picker column "Leader", now when we create a new item in List 1 it should copy the value of "Manager" to "Leader" field in the item created in List 2, Below is the workaround for it:

1) Create a string Workflow variable "userM".

2) Assign it a value like below:

Set userM to [Current Item: Manager];#[Current Item: Manager]

Here for the first [Current Item: Manager] - Return the field as "User Id Number".

for second [Current Item: Manager] - Return the field as "Display Name".

3) Create the item in List 2.

Set "Leader" Column value to Workflow variable "userM".

Answer 4

I have resolved this issue as below without giving pause.

There was local variable to store the SharePoint group name based on a condition. And this variable is used inside the Approval task as participants. I have removed the local variable and changed the participants inside the task as SharePoint group.This resolved the issue.

Seems like the SharePoint group name assigning to a local variable and using that variable inside the task is creating issue.

Answer 5

RESOLVED: When I change my User Field assignment (Technical Manager) assignment from other User Field (Tech Manager) I changed the "Return Field as" to User Id Number, then it worked well. This makes sense to me, as it was happening to only one user name "Jon Williams". With this name in my organization there were two people (with same display name), so i was having issues, when I changed it to User ID number it was using SharePoint User Id. SharePoint User Ids for the two people were different (one is 169 other is 87), so it worked...