Currently I have been helping a friend of mine fixing some Nintex Workflow 2010 issues, one of the issues he had was an error appearing in the workflow stating that:

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

OK…! As can be seen; this error (along with other SharePoint generic errors) doesn’t give us much detail about the problem, you can’t start investigating this kind of problems without copying this error message and pasting it in Google and start Googling.

The purpose of this article is to know how to troubleshoot a workflow without needing to search on Google, and for sure to tell you what caused this error.

Nintex workflow is like any other workflow tool (ex: SharePoint Designer), it will provide you with a set of actions that you can use to construct the logic of the workflow and achieve what it is intended to do. Let’s take the scenario of an approval workflow, where the submitted document goes to the manager along with a custom notification email, upon approval or rejection, the document will be sent to the next manager, or to the initiator to tell him the reasons of the rejection, if the workflow consists of only one approval step, it would be easy to troubleshoot, because the scope of the problem is limited to only these few actions, but what if you have a workflow that consists of: Switch statements, foreach, state machine, long approval process (more than 5 approvers)? If you get an error in these steps, it will be tough to figure it out.

Here comes the need for something to trace the workflow and to know where the workflow actually went wrong, one way (easy way) is to use the workflow history diagram, you can get to this diagram from the item’s options menu, view the figure below:

When clicking this option, you will be redirected to a page with all workflows that are running on the current item, as can be seen, there are 3 categories where the workflow on the current item can be categorized:

As you can see, our workflow instance is classified as an erroed workflow, if you click on the workflow name, you will see where the workflow really stopped:

The yellow background means that the workflow stopped here, if the workflow passed the action, it will be colored green, but in our case it’s yellow, which means that the workflow has stopped at this action. If you click on the “Click here to show detailed view”, you will be transferred to a page detailing the workflow error, in our case, we didn’t configure the outgoing email settings in Central Administration, so the workflow errored on sending email action:

The problem with this kind of troubleshooting is that this diagram is not always accurate, it might be freezed on specific actions although the workflow has passed these actions. The better way to troubleshoot the workflow is to add your own tracing values, suppose that the outgoing email settings are configured in Central Administration, but you may also get an error in the workflow for some reason (your mission is to know what’s that reason), or the workflow ran without any issues but the logic that the workflow executed is just wrong!

In this case we can use the awesome “Log in history list” action, this action is useful if you are making some calculations in the workflow and you want to make sure that the result of these calculations are right, or if you are having an error in the workflow, but the workflow history diagram just got stuck (which sometimes happen), in this case it would be best to log to the history list before any major action that you think would cause an issue, like sending emails, assigning tasks, granting and revoking permissions, etc..

When the workflow is running or stopped, you can just navigate to the workflow history, by clicking on the workflow’s status column in the list view, and if you have logged for example: “Next action: Sending an email to Marketing Manager”, and it was the last log that was written before an error is occurred, you will know directly that the action responsible for sending an email to the marketing manager is making the trouble for you. This way you will guarantee you will know what the exact error is regardless the fact that the workflow history diagram may work or not.

Back to the error stated in the beginning of the article:

“The workflow could not update the item, possibly because one or more columns for the item require a different type of information”. The workflow history diagram was stuck on an action, but in fact the workflow wasn’t really stuck, so don’t always trust the workflow history diagram. Placing a log to history action before main workflow actions, I could know what was causing the error, it turns out that the cause is done by “Set item permissions” action, in this case the action was misconfigured to break the inheritance from the library, AND remove all users permissions was checked, so on the next item edit, the workflow will throw an error, see the figure below:

As can be seen, the item was breaking the permission inheritance from the parent library, and it also removed the permissions that already existed on the current item, which will prevent the modification of the item.

After testing the workflow thoroughly; make sure to remove/disable the log to history actions because each action inserts a new item in the history list in SharePoint, which you should not do in order to avoid filling the list with arbitrary testing values.

Conclusion:  You can get away with a short process workflow without doing the extra effort of adding log to history list action, you can use the workflow history diagram but you can’t always trust it because it can get stuck sometimes and not show you the real progress of the workflow.