I have an SPD 2013 workflow attached to a list. The workflow is set to start when an item is added to the list. The workflow works just fine when a list item is added from the sharepoint website because it runs under the user's credentials.

The workflow fails immediately when the list item is added from Sharepoint webservices since it attempts to run the workflow with the "System Account" credentials. I know it fails immediately since the first action in the workflow is to log a start message to the history list. Can anyone tell me how to get arround this?

Here is the error reported from the Internal Status field.

RequestorId: 056b2801-f584-224e-7496-66eddbc3aec6. Details: System.ApplicationException: HTTP 401 {"Transfer-Encoding":["chunked"],"X-SharePointHealthScore":["0"],"SPRequestGuid":["056b2801-f584-224e-7496-66eddbc3aec6"],"request-id":["056b2801-f584-224e-7496-66eddbc3aec6"],"X-FRAME-OPTIONS":["SAMEORIGIN"],"MicrosoftSharePointTeamServices":[""],"X-Content-Type-Options":["nosniff"],"X-MS-InvokeApp":["1; RequireReadOnly"],"Cache-Control":["max-age=0, private"],"Date":["Wed, 31 Jul 2013 21:45:36 GMT"],"Server":["Microsoft-IIS/7.5"],"WWW-Authenticate":["NTLM"],"X-AspNet-Version":["4.0.30319"],"X-Powered-By":["ASP.NET"]} {"error":{"code":"-2147024891, System.UnauthorizedAccessException","message":{"lang":"en-US","value":"Access denied. You do not have permission to perform this action or access this resource."}}} at Microsoft.Activities.Hosting.Runtime.Subroutine.SubroutineChild.Execute(CodeActivityContext context) at System.Activities.CodeActivity.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager) at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation)

3 Answers 3


Activate site feature "Workflows can use app permissions"

Site actions > Site Settings > Site features > Workflows can use app permissions


Wow, you would have thought Microsoft would have fixed this by 2013! This may answer your question: http://blogs.technet.com/b/victorbutuza/archive/2009/03/14/workflows-do-not-start.aspx

Basically, don't use System Account (which may not be possible in your case...). Try adding an impersonation step to your workflow so that it works within the context of the user who created the workflow.

  • 1
    They fixed it back in 2007 Service Pack 2 as a security feature, which makes sense. Aug 1, 2013 at 3:46
  • Only to reappear in 2010: support.microsoft.com/kb/2496152 I believe this is one of the reasons SPD introduced the impersonation step in SPD workflows. Aug 1, 2013 at 12:01
  • It was moreso to allow users who don't need full contribute access to update list metadata in workflow processes without giving them more privledge than they need. Aug 1, 2013 at 15:01
  • Unfortunately it does not seem like they included any impersonation actions in SPD 2013.
    – Chandler
    Aug 1, 2013 at 20:21

I had the same problem in past, but only specific to Visitors. People having contribute permission were able to run the workflow successfully.

After having thorough observation I come to know that workflow initiator is a Visitor and there were two lists supposed to be updated by workflow internally with the account of Visitor. I added custom level permission (Add and Edit) to those two lists for visitors group from Library Setting-->Permission to this library by breaking the permission inheritance. After that I set the Item level Permission to Create items and edit items created by user. This resolved my issue. You can find this option under advanced setting.

You may also need to ensure that User Profile Services are synchronized properly.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.