Flexitask errors after user responded. Unauthorized attempt to update workflow task by [username]

Hi,

are your users replying via LazyApproval? Then this might be helpful

Error "Unauthorized attempt to update approval task by DOMAINUsername" in LazyApproval Email - Nintex Knowledge Base 

Best regards

Enrico

Hi,

thanx for reply. I have seen that article... Nope, no Lazy approval. Assignee has to go to the task item and approve/reject it there.

any further details on your design so that we could better picture what might be going on there?

do you assign task to a dedicated user? or SP/AD group?

single user per each task or multiple users?

individual tasks or not?

do you have configured escalation that may close a task before it is responded? any other way how a task could be closed or responded (other workflow, web service call, wf restarted...)

can users delegate task, or did you configure escalation to delegate? don't they respond to delegated task?

does the workflow/task action(s) run with initiator credentials or wf publisher ones? or even kind of mix?

have you tried to investigate ULS logs for further details?

I recall several threads discussed similar problems with task actions running within parallel action, this approach doesn't sound to be be reliable. you've likely already seen them...

I'd suggest to spin off content of single parallel branches (task actions) to a separate workflow(s)

Thanx for the response Marian

Tasks are assigned to users. 4 of the flexitask actions assign them to individual user, 5th can be to multiple users. Individual tasks are set only for the 5th flexitask action

There is escalation configured but in each of these faulty cases the task has been responded to by its original assignee. It also was not delegated to anyone. There are no other wfs or web services actions which would close the task. The task is actually responded to by the assignee the error occurs after the response is given.

The wf actions run with publisher's credentials who is SC admin.

Yes, I did look into ULS logs with Medium trace level but there was nothing of a value other then what wf status error message already said to me. Since this issue appears very sporadically and it is virtually impossible to reproduce then raising the log level to Verbose and waiting several days or weeks before it re-appears is not really an option for us.

I have seen some discussions you mention and yes, we have pretty much already decided to redesign the workflow as there is also quite a big change request coming from the business.

BR

Jan

to be honest I'm running out of further ideas.

since you're going to redesign the workflor I'd guess it's not worth of spending time on it anymore...