can you post a screenshot of your workflow to see what then mean with parallel approval if you do not use parallel action?

do you assign the task to a group? have you tried to 'create individual tasks for all group members'?

I'm not Ganesh but have the same problem and can hopefully explain:

in a scenario, where you don't know the approvers (and the number of approvers) in advance, the flexi task comes in handy. The workflow looks up the approvers in a configuration list, stores them in a collection variable and then uses one flexi task action to assigne the tasks at once. Works perfectly well.

But some users get the task-locked message when trying to respond to the task. On our servers it can take up to an hour till the task becomes unlocked while some tasks are not locked at all. And this can happen within the same workflow instance, meaning in the same instance from the same flexi task action some tasks are locked and some are not.

have you seen this document Task Lock - Task is locked by a running workflow and cannot be edited

are the approvers end users or are they (as well) AD groups?

if you assign task to an AD group, you can not avoid locks completelly since all the AD group members work on the same task instance. if two of them try to work on a task right at the same time, one of them will definitely experience a lock.

The approvers are all persons i.e. users in SharePoint and each of them gets his own task. Some of those tasks are locked, some are not.

I've now disabled the mails from the flexi task action and send them from a secondary workflow on the task list. There is a pause of two hours in this workflow before it sends out the mail so the task will be unlocked till then. Now the users complain because they do not get mails if a task is delegated to them :-(

have you got rid of locks with that delayed notifications?

have you investigated performance of your env? I can imagine that if users try to respond tasks right after they receive notification mails not all the things need to be 'settled' internally within sharepoint already.

Well, I did not actually get rid of the locks because of the delay, but the users won't see the lock-messages anymore, because they get the mails delayed.

And of course there is something "not settled", but come on, two hours??? Overall performance on this server is very good.

have you applied any other customizations on Task List (apart from notification workflow)?

how big is the Task List? haven't you tried to define separate Task List for each such a workflow that experience these locking issues?

There are no other cutomizations and the task list is still very small. The "application" is still in testing and and one of the encountered problems while testing was the task locks.

how deep within workflow (how many actions) is flexi task?

can you try to place pause action at the very begining of the workflow?

The whole system consists of one main workflow which is basically a state machine calling different sub workflows. The sub workflows are not too complex and they all have a pause at the beginning.

hm, that's weird. I'm running out of ideas.

something apparently takes much longer then it should in the background.

would you mind sharing screenshot of your workflow, at least path from beginning of master workflow till flexi task in child workflow is reached?

just to get an idea what's going on there down the way.

I understand that you are running out of ideas - that's what I'm struggling with for weeks ;-)

The workflows "belong" to a customer and I don't want to make them public without consent (which could take some time).

The workflows are quite big, but not very complicated. The main workflow is mainly a state machine. Each state calls a sub workflow. The sub workflow sets a hidden field before ending which the state machine then reads. Depending on this "outcome" it goes to the next stage or ends.

The sub workflows do look for responsible persons which could be a more or less complicated thing. It is done by reading at least one list by using the Query List action. In some cases it's necessary to query another list as well. All those users are stored in a collection variable and the flexi task is assigned to this variable. No magic involved.

And I don't see why anything done before the task is asigned could affect the task locking behaviour...

But anyway, thanks for trying to help!

ok, I understand.

any chance you get a correlation ID with task locked message?

or any other clues from ULS logs?

here I find a piece of code that should be capable to release the lock This task is currently locked by a running workflow and cannot be edited ​

even if it might not be the best idea to force lock release on prod env, however, if you examined other properties of used SPBuiltInFieldId class it might point you to a direction what/when/why locks your task.

when I googled a bit about the problem I found a mention that it happened when 'Workflow Services were running on different servers in the farm at the same time'.

so, you may want to check whether your underlying infrastructure is set up properly.

Hi Marian, I really appreciate your effort ;-)

I searched ULS logs up and down but unfortunately to no avail. I'm sure there must be something there, but couldn't find it so far. The problem here is, that it is not foreseeable when a task ist locked and when the users tell me,  most of the time it is too late. And of course they can't remember the exact time when they tried...

Regarding the other thread: I know about this trick with setting the Workflow Version field. I think it is there since SharePoint has workflows (2007?). Perhaps I will give it a try when I can get hold of a locked task myself.

And regarding the last one: we have only one machine yet in the farm, but thinking about adding another one (due to different reasons). Do you think it is a problem when we activate the workflow service on more than one machine? I don't think this should matter and of course having it on more machines is in respect of things like availability and such.

Cheers, Andi

Do you think it is a problem when we activate the workflow service on more than one machine?

I'm not SP infrastructure expert, I'm not able to give you reliable answer.

one last think (for now ), could it be that you have on the list of assignees user accounts that are not in AD (anymore)?

I have seen issues caused by that. maybe it just takes too much time to resolve whole list.

At the moment I'm sure that all assignees are valid AD users, because we are still doing tests with "only" about 20-30 persons. And they are all there and responding to their tasks if possible.