locked
The workflow could not update the item, possibly because one or more columns for the item require a different type of information RRS feed

  • Question

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

    Outcome : Access Denied

    We are having our Sharepoint workflow automattically canceling??  Every once in awhile this would happened.

    ANy experiences out there? Thanks This has been bothering me for weeks

    Thursday, February 16, 2012 10:20 PM

Answers

  • the issue here was my permissions on initiators!!

    http://social.technet.microsoft.com/Forums/en-US/sharepoint2010general/thread/7ce7e2b2-2fda-4ec6-ac1a-8f7d33e831f0

    this is why I was getting the error. Once I added all authenicated users to the sharepoint group. Problem resolved. no more canceled workflows.

    <ins>Workflow Permissions:</ins><ins></ins>

    <ins>It is very common for developers of workflows in SharePoint to have elevated permissions on the SharePoint Site Collection in comparison to the general end-users of the SharePoint environment. This can lead to workflows not functioning as expected, or not working at all once in use, as testing may have been completed using the permissions of the workflow developer. To help prevent access / permission issues with workflows in SharePoint, you should always thoroughly test workflows using accounts with identical permissions to end-users of the SharePoint environment and workflow. In some cases this may require you to test using multiple accounts with varying permissions matching that of the end-users, or to change the permission level of one or two test accounts in order to test all possible scenarios.</ins>

    <ins>As a workflow runs using the permissions of the user who initiated / triggered the workflow, in many cases during development it will be running using the credentials / permissions of the developer. If the developer has elevated access to components on the SharePoint site including lists associated with the workflow, the workflow will often function as expected during development, but not work once deployed into a production environment. </ins>

    <ins>
    Resolution / Workaround:</ins>
    <ins></ins>

    <ins>When a workflow is initiated by a user with standard permissions, and the workflow needs to complete actions that would require the user to have a greater permission level on the site and lists, you can split the worklfow into components which are then initiated by users with the required permissions.</ins>

    <ins>For example, a general user may make a change to a document stored in a document library with content approval enabled. A custom approval workflow is initiated to create and assign tasks to have the changes approved. As the Approval Task is created by the workflow running as the user who submitted the changes for approval, the user requires permissions that allow them to add items to the Approval Task list.</ins>

    <ins>If using the "Collect data from user" action to get the approval status of the changes from an Approver, the workflow will continue to run as the user who initiated the worklfow (not the approver) once the approval status has been collected. This will result in a Workflow error if you try to update the approval status of the list item or document, as the user who made and submitted the changes for approval doesn't have approve permissions on the list/library. A solution for this problem is to split the workflow into two separate workflows. One to initiate the approval process and create the approval task item, and a second workflow on the Workflow task list which will be initiated by the approver when the approval status for the changes is set. You will not be able to use the "collect data from user" action, as this will result in the workflow continuing using the credentials of the user who initiated the workflow and a workflow error when attempting to set the Approval Status. Instead, you should create a new content type with only the fields required to collect the Approval Status for a modified list item and use the "Create List Item" action to create the Approval Task. Once created, associate the content type with a task or other list type, making it the default and only content type available on the "New" menu for the list. In the workflow associated with the content approval enabled list, you should use the "Create List Item" action to add an Approval Task item to the task list, then complete the workflow (Stop).</ins>

    <ins>The Second workflow associated with the task list should be configured to initiate when an item in the Approval Task list is modified. The first step in the workflow should be to check to see if the Content approval status has been set by the approver. If not, then the workflow can stop as it will be reinitiated when the approval status is updated by an approver. If the approval Status has been set, then the workflow can continue to update the Approval Status of the list item or document that was changed and submitted for approval. The approval status can now be set by the workflow as it will be running using the permissions of the approver, not the user who initiated the approval process.</ins>
    • Marked as answer by SPWizard Friday, April 27, 2012 1:21 PM
    Friday, April 27, 2012 1:21 PM

All replies

  • I found this

    http://antclegg.blogspot.com/2012/01/workflow-could-not-update-item-possibly.html

    But I am already using the set current item task.  Ialso had several workflows cancel on me with no reason in the workflow history.  It happens sporadic but seems to be at the same spot in one workflow. I checked the user and he has contribute permissions. I just added an approver permissions to the list.

    Thursday, February 16, 2012 10:43 PM
  •  

    Hi SPWizard,

    Is there a content type in your list item? I think this is the content type need the permission.

    For more information, please refer to:

    Use a workflow to manage content approval for a library: http://office.microsoft.com/en-us/windows-sharepoint-services-help/use-a-workflow-to-manage-content-approval-for-a-library-HA010154436.aspx

    Plan content approval and scheduling: http://technet.microsoft.com/en-us/library/cc263156(v=office.12).aspx

    Thanks,

    Jack

    Sunday, February 19, 2012 8:43 AM
    Moderator
  • It is not a list item. TEchnical its an infoapth form so not sure what you mean by content type and list irem
    Monday, February 20, 2012 7:30 PM
  • some solutions I came across are:

    1. check permissions on initiator and approvers

    2. add a pause task before the task where the workflow is canceling

    3. validate the workflow for errors

    4. avoid blank fields when submitting the form(but the workflow requires them)

    5. configured clients' locale to match the server's locale,

    6.  change the first line in the code to wait until the document is loaded

    7.any others I may be missing? This issue us hard to troubleshoot and this workflow is long to re create

    Wednesday, February 22, 2012 1:30 PM
  • Hi SPWizard,

    I suggest you to check your business logic in your SharePoint Designer.Have you ever doing some changes on your workflow? From the current situation, there is no more detial about it to fix it.

    You can have a try to open your SharePoint designer ,find your workflow, then check out it, then check in it. then test it again.

    Thanks,

    Jack


    Thursday, February 23, 2012 5:16 AM
    Moderator
  • the issue here was my permissions on initiators!!

    http://social.technet.microsoft.com/Forums/en-US/sharepoint2010general/thread/7ce7e2b2-2fda-4ec6-ac1a-8f7d33e831f0

    this is why I was getting the error. Once I added all authenicated users to the sharepoint group. Problem resolved. no more canceled workflows.

    <ins>Workflow Permissions:</ins><ins></ins>

    <ins>It is very common for developers of workflows in SharePoint to have elevated permissions on the SharePoint Site Collection in comparison to the general end-users of the SharePoint environment. This can lead to workflows not functioning as expected, or not working at all once in use, as testing may have been completed using the permissions of the workflow developer. To help prevent access / permission issues with workflows in SharePoint, you should always thoroughly test workflows using accounts with identical permissions to end-users of the SharePoint environment and workflow. In some cases this may require you to test using multiple accounts with varying permissions matching that of the end-users, or to change the permission level of one or two test accounts in order to test all possible scenarios.</ins>

    <ins>As a workflow runs using the permissions of the user who initiated / triggered the workflow, in many cases during development it will be running using the credentials / permissions of the developer. If the developer has elevated access to components on the SharePoint site including lists associated with the workflow, the workflow will often function as expected during development, but not work once deployed into a production environment. </ins>

    <ins>
    Resolution / Workaround:</ins>
    <ins></ins>

    <ins>When a workflow is initiated by a user with standard permissions, and the workflow needs to complete actions that would require the user to have a greater permission level on the site and lists, you can split the worklfow into components which are then initiated by users with the required permissions.</ins>

    <ins>For example, a general user may make a change to a document stored in a document library with content approval enabled. A custom approval workflow is initiated to create and assign tasks to have the changes approved. As the Approval Task is created by the workflow running as the user who submitted the changes for approval, the user requires permissions that allow them to add items to the Approval Task list.</ins>

    <ins>If using the "Collect data from user" action to get the approval status of the changes from an Approver, the workflow will continue to run as the user who initiated the worklfow (not the approver) once the approval status has been collected. This will result in a Workflow error if you try to update the approval status of the list item or document, as the user who made and submitted the changes for approval doesn't have approve permissions on the list/library. A solution for this problem is to split the workflow into two separate workflows. One to initiate the approval process and create the approval task item, and a second workflow on the Workflow task list which will be initiated by the approver when the approval status for the changes is set. You will not be able to use the "collect data from user" action, as this will result in the workflow continuing using the credentials of the user who initiated the workflow and a workflow error when attempting to set the Approval Status. Instead, you should create a new content type with only the fields required to collect the Approval Status for a modified list item and use the "Create List Item" action to create the Approval Task. Once created, associate the content type with a task or other list type, making it the default and only content type available on the "New" menu for the list. In the workflow associated with the content approval enabled list, you should use the "Create List Item" action to add an Approval Task item to the task list, then complete the workflow (Stop).</ins>

    <ins>The Second workflow associated with the task list should be configured to initiate when an item in the Approval Task list is modified. The first step in the workflow should be to check to see if the Content approval status has been set by the approver. If not, then the workflow can stop as it will be reinitiated when the approval status is updated by an approver. If the approval Status has been set, then the workflow can continue to update the Approval Status of the list item or document that was changed and submitted for approval. The approval status can now be set by the workflow as it will be running using the permissions of the approver, not the user who initiated the approval process.</ins>
    • Marked as answer by SPWizard Friday, April 27, 2012 1:21 PM
    Friday, April 27, 2012 1:21 PM
  • A simpler solution would be to use the 'Impersonation Step' in SharePoint Designer. In a blank area of your workflow design canvas in Designer, look for the button on the ribbon called Impersonation Step. This will run workflow actions within that step as the workflow author (which could be a farm or site collection administrator). This will allow your workflow to update any item or column without permission problems.
    • Proposed as answer by SubNet.Zero Wednesday, July 31, 2013 3:08 PM
    Monday, August 13, 2012 1:02 PM
  • Hello,

    I encountered the very same problem. Mine's a designer workflow and I figured out its a permissions problem and tried using a Impersonation step to do the activity. Well, this solved the issue. 

    The activity all about moving a list item to another list after it gets approved. Hope it wont be a issue?

    Anyone some insight please?

    Regards

    Vivek


    Thursday, January 3, 2013 8:08 AM
  • I had the same issue but a different cause. What may be of value to others is what caused the issue but how I went about solving it.

    I had a 30-odd step workflow which has a 'log [comment] to the workflow history list' step about every three steps to help me debug. I made what i thought was a small change and ran out of time before i could thoroughly test it, then went ahead and published it anyway (don't ask). A week later i returned to the project to discover that my workflow was now generating the 'The workflow could not update the item...' error, and none of my comments were showing up in the history list.

    After much trial and error I discovered I could get the workflow to run part-way by inserting a 'Stop' step. I started with the Stop step at the very top, then moved it down the workflow step by step, publishing the change and then running the workflow each time to make sure the 'The workflow could not update the item...' error didn't occur. When it DID occur is when I found the error in my logic, which was that I assigned a long string without the required comma + space to a hyperlink column.


    Martin Cunningham

    Thursday, January 24, 2013 2:45 AM
  • Seems to me this happens for many reasons.  The reason I got this message was because my Sharepoint wasn't linked to either Active Directory or any email system and in the workflow I had selected Person or Group field to a current user's account email address.
    Wednesday, April 10, 2013 8:58 PM
  • If it is happening randomly I think it is pretty safe to rule out the permissions issue.
    Wednesday, October 23, 2013 3:47 AM
  • Hi,

    I had the same problem, but the outcome was not "Access Denied" was "Approved"

    I had developed the workflow in a test server, equal in every aspect to the Production Server.

    My problem was that I had make a Workflow List, and not a global workflow, so I was unable to export to the other server. But using Google, i found a post of someone with a very clever workaround to be able to export the workflow, http://blogs.technet.com/b/wkng/archive/2012/08/21/exporting-and-importing-sharepoint-designer-2010-list-workflow.aspx. So i followed  the steps and everything seamed Ok, until I tested the workflow and started to have that error!

    So I had to go line by line to try to find why I could n´t update the column that was just "Update Item" "A/F=Closed" but I had 3 variables that I needed to write the comments from the task form to a column in my list"Observations"  and i discover that the workflow had lost the column name.  I resolved the problem, tested again with another item, but the problem persisted!

    after some time, looking for solutions, I decided to Stop the workflow, to cancel all the task, and start again with the same items already created but modified in the columns that trigger the workflow to start.

    And it worked, without errors, everything fine..

    I hope, I can help someone.

    Wednesday, April 30, 2014 1:28 PM