We are having a problem with a workflow getting stuck at a Request Data action. 99% of the time, this action completes successfully and the workflow moves on to the next action. Once in a while however, although the workflow history shows that the task status is Completed, the workflow outcome remains at Pending forever:
We are using SharePoint 2013, which is up to date, and Nintex Workflow and Forms 2013 which are also up to date.
The Request Data action has a Nintex Form within it. LazyApproval is disabled; users respond only via desktop, no mobile. The task is assigned only to one individual, using a previous set variable action. There are no reminders, and no escalation. It uses an existing (custom) content type. Variables are provided to receive the data for each content type column:
There is also a Set Item Permissions action, prior to the task, which grants the user-to-be-assigned Full Control access to the item the workflow is running on. Existing permissions are not removed.
The person who was assigned the third task in the first screenshot, where the workflow has gotten stuck, has been assigned this Request Data task before, on a different item, and the workflow completed successfully. There are other users where the workflow has gotten stuck as well, who have also had the workflow complete successfully on other items.
What are some possible causes for this please? Is there any way to force this workflow to continue? How can we prevent this from happening?
P.S. @emha here is the new post you suggested I write
do assignees experience any error while submitting task response?
is it possible that somebody/something (workflow, webservice, ...) changes directly task list item (out of the task form)?
couldn't it be after the task was was approved by approver?
do you have enabled versioning on task list to see what changes are performed on task list item?
do you have option to 'Save and continue' or 'Save' (without submit) on task form?
do you have availbale 'Status' field changeable from task form>?
do you upload attachments with task response? any bigger ones? or any higher number of them?
would you be able to investigate (ev. upload) ULS logs from the time the problem happens?
Thank you for your troubleshooting suggestions @emha .
I have checked everything you asked, and found one thing. All of the tasks that have status Completed and outcome Pending show the Assigned To as the Modified By. All of the tasks where the status is Completed and the outcome is Continue show System Account for Modified By. What might cause the System Account not to modify the task outcome?
In answer to each of your questions,
Assignees do not receive any error message.
I can't imagine that anyone is editing the task other than with the form that is in the workflow task action. The task list has no workflow. I have turned on versioning on the task list so that we can check this to find out for sure, next time this happens.
There are only two buttons on the form. One has the Save and Submit action, and the other has the Cancel action.
The Status field is not on the task form.
There is only one task out of 2482 that has an attachment. This attachment is a small email file.
I would have to ask a colleague to look at the ULS logs.
I appreciate any further thoughts you may have.
What might cause the System Account not to modify the task outcome?
that's the question!
task response is processes in two steps - first Status field is updated with user credentials workflow is running with, then read-only outcome field is updated by system.
I suspect there are some locking issues, but I do not know for sure what may cause them in your env.
I'm affraid this only could be identified from ULS logs (*could*, but need not neccesarily be...)
you know your setup and application better, try maybe think of what might be done on task in parallel, what might block mutually.
try to get in contact with people who responded failed task, maybe they do response in some unexpected/unforeseen way (eg. they respond too quick, before task and task item is fully settled - I remember such discussions on the community)
if you could enable verbose logging it might help as well, since from verbose log you can get event timestamps at miliseconds level which help to significantly reduce amount of ULS log entries to investigate.