This task is currently locked by a running workflow and cannot be edited.
"This task is currently locked by a running workflow and cannot be edited" is a common message which is seen when an error occurs while the SharePoint workflow engine is processing a task item associated with a workflow.
When a workflow processes a task normally, the following sequence of events is expected to occur:
When the message is encountered, it usually indicates that an error occurred between step 2 and 4. As a result, the lock is never released.
Therefore, the ‘task locked’ message is not an error itself, rather a symptom of another error - the ‘task locked’ message does not indicate what went wrong. In most cases, once this message is encountered, the workflow cannot be made to continue and must be terminated and started again.
The following is a guide that can help troubleshoot the cause of these messages. Some initial observations to narrow down the potential causes are:
Is the error consistent or intermittent?
When the error is consistent, it will happen every time the workflow is run. When it is intermittent, it may happen regularly, but not every time.
Does the error occur the first time the user tries to respond to a task, or do they respond and notice the workflow does not continue, and when they respond again the error occurs?
If the message is present when the user first responds to the task, the issue would have occurred when the task was created. Otherwise, it would have occurred when the user attempted to respond to the task.
Modifying the task list
A cause of this error appearing consistently the first time a user tries to respond to a task is a modification to the default task list schema. For example, changing the ‘Assigned to’ field in a task list to be a multiple selection will cause the behaviour.
Parallel simultaneous responses
A cause of this error appearing inconsistently is multiple users responding to tasks in parallel at the same time. In this scenario, one task will complete correctly and the other will not process. When the user tries again, the ‘task locked’ message will display.
Additional processing on the task
A cause of this error appearing consistently and inconsistently is having an additional system running on the items in the task list. Some examples include; a workflow running on the task list, an event receiver running on the task list or another automated process querying and updating workflow tasks.
Note: This Microsoft help article (http://office.microsoft.com/en-us/sharepointdesigner/HA102376561033.aspx#5) explains creating a workflow that runs on the task list to update a field on the task. Our experience shows that this causes the ‘Task Locked’ issues when the ‘parent’ workflow is generating more than one task at once.
Isolated system error
If the error is a rare event, or a ‘one off’ event, then an isolated system error may have occurred.
For example, if there is a database connectivity issue while the workflow is processing the task response, the task will lock. In this case, the user will respond to a task but the workflow will not continue. When they respond again, the ‘task locked’ message will display. In this case, there will be an error in the SharePoint ULS Logs at the time that the user originally responded.
Temporary delay while workflow processes
If the workflow is taking a long time to process after a user submits a task, they may notice and try to respond to the task again. They will see the task locked error, but after a number of attempts (or after waiting some time) the task response page eventually indicates the task has been responded to. In this case, nothing actually went wrong, and the error message gives an accurate indication of what is happening – the workflow temporarily locked the task while it was processing. This scenario may occur in a very large workflow, or after the SharePoint application pool has just started.
Modifying the task via a web service with an invalid url
If the Nintex Workflow web service is used to respond to or delegate a task, the site context part of the url must be a valid alternative access mapping url. For example, if you access the web service via the IP address of the SharePoint server, and the IP address is not a valid AAM, the task can become locked.
The workflow has become stuck without any apparent errors
This behaviour can occur as a result of a bug in the SharePoint 2010 workflow engine. If you do not have the August 2010 Cumulative Update (or later) for SharePoint, and your workflow uses delays, "Flexi-task", State machine", "Task Reminder" actions or variables, you could be affected. Check the SharePoint 2010 Updates site here: http://technet.microsoft.com/en-us/sharepoint/ff800847. The October CU is recommended http://support.microsoft.com/kb/2553031. The fix is described as "Consider the following scenario. You add a Delay activity to a workflow. Then, you set the duration for the Delay activity. You deploy the workflow in SharePoint Foundation 2010. In this scenario, the workflow is not resumed after the duration of the Delay activity".
If you find this is occurring in your environment, install the October CU, terminate all the running workflows affected and run them afresh.
The first step to isolate the issue is to create a new task list on the site and configure the workflow to use it. Any customizations that were made to the original task list should not be made to the new task list. If the new task list eliminates the issue, then the cause can be attributed to the original task list or a change that was made to it.
To change the task list that the workflow uses:
1. In the Workflow Designer select Settings.
2. Towards the bottom of the Workflow Options section, select the Task List drop down menu to configure the task list as required.
If any of the scenarios above do not help, check the SharePoint logs for any messages with a category of ‘Workflow Infrastructure’.
The information in this article has been gathered from observations and investigations by Nintex. The sources of these issues are the underlying SharePoint workflow engine.
I had this issue and was troubleshooting for months when these solutions didn't help. Here is the solution in my case and found it when searching for "SharePoint Approval Tasks lock after 24 hours" and it's related to tokens and permissions.
There are two domains involved with the SharePoint Farm. One is a Resource domain and another is the User domain. The SharePoint farm is in the Resource domain and the users are in the User domain. There is a one-way trust from Resource domain to User domain. User Accounts from the User domain are members of Security Group (SG). Permissions are set inside the SharePoint site collections by using the security group.
SharePoint stores the User-Token in a SQL table and some services will check that token before contacting a Domain Controller again. The default timeout for this token is 24 hours. After 24 hours, when the token expires, interactive logon creates a fresh right-token in the SQL table. The scheduled workflow task is picked up by OWSTimer job, and at that time, OWSTimer tries to update the User-Token. If OWSTimer Service account is from Resource Domain, it cannot retrieve the membership in the User Domain. The User-Token turns invalid and the workflow task fails to execute because the invalid User-Token triggers an 'Access Denied' error.
Change the OWSTimer service account to be an account in the User Domain.
Thank you Peter because your answer has the merit to give some resolution options, whereas the initial article describes an issue to re-assure people that this is not their fault (not that reassuring!).
I have a follow-up question regarding the paragraph showing consistent error when this may have been the case : "Modifying the task list" So are we saying that the task list used by a running workflow can never be altered, otherwise we would have to stop the 300 workflow tasks and restart them ? This is quite major in any organisation and would mean that although Nintex Workflow are easy to update, if they use custom Nintex Forms within the workflow then the form design of these cannot altered after production release.
So we just contacted Nintex since we are seeing this error in our environment and their response was to contact Microsoft since it's a SharePoint issues.
Which is interesting since what we've seen in our testing, is if we use the link and actually go to the task itself to approve we don't get any task is locked by another user errors. These errors only seem to occur when we use the lazy approval emails.
It also only seems to occur intermittently, and only when people are either approving items right away, or if multiple approvals are being submitted in the same time frame. In theory this shouldn't matter, since the workflow is setup so each individual has their own task. But that seems to be what is causing an issue on the SharePoint side.
We had struggled with this task locking problem for a few months. It seemed that the problem started after making updates from Microsoft and Nintex. After some digging, I found out the problem in our environment thought I would share.
One of the updates (not certain which one) disabled one of the timer jobs in SharePoint. The fix for us in was the following:
Immediately, I received a bunch of notices/reminders from workflows that ran since the updates. After about 5 minutes or so, all workflow tasks that work locked completed successfully and workflows were moving again. If you are stuck, I recommend taking a look at the "Workflow" timer job and make certain it is running. Hope this helps someone out there.
I have just experienced this problem
and noted that we have had a similar issue with our SharePoint site being slow creating tasks etc. previously.
Is there anyway of putting a "pause" on the workflow or issuing emails out? I has noted that when an approver clicks on the link the second time (or waits after quite some time) there are no error messages and they are able to approve/reject without any issues.
Any ideas appreciated!
You can add a PAUSE action or WAIT FOR ITEM UPDATE action yes, to make sure it gives enough time.
Is that your question?
Hi Francois Souyri
Yes I was asking about a "Pause" action. I.e. pause for a duration to give enough time for SharePoint to finish creating the Workflow items.
I am just getting used to all the items in workflows again (been concentrating on building my form)
I have now found these-
and "Wait for Item Update"
I will need to configure them into my workflow as I am not used them previously. Hopefully these will avoid the errors that I am having on my SharePoint environment.