I have a SPD 2013 list workflow that is scheduled to start as soon as a list item is created or changed. The first phase of the workflow is an if-cascade that re-routes the flow to the correct phase.

If I (as a site collection administrator) create a list item, the workflow is started successfully and executes the subsequent phases. If other users (who are not site collection administrators) try the same procedure, the workflow is created, but it stops after a few seconds with the following error message:

RequestorId: d76ec137-0aff-c40c-0000-000000000000. Details: An unhandled exception occurred during the execution of the workflow instance. Exception details: System.ApplicationException: HTTP 401 {"error":{"code":"-2147024891, System.UnauthorizedAccessException","message":{"lang":"de-DE","value":"Access denied. You do not have permission to perform this action or access this resource."}}} {"Transfer-Encoding":["chunked"],"X-SharePointHealthScore":["0"],"SPRequestGuid":["d76ec137-0aff-c40c-825e-6b48ddf9a38f"],"request-id":["d76ec137-0aff-c40c-825e-6b48ddf9a38f"],"X-FRAME-OPTIONS":["SAMEORIGIN"],"MicrosoftSharePointTeamServices":[""],"X-Content-Type-Options":["nosniff"],"X-MS-InvokeApp":["1; RequireReadOnly"],"Cache-Control":["max-age=0, private"],"Date":["Wed, 06 Jan 2016 12:08:11 GMT"],"Server":["Microsoft-IIS/8.5"],"WWW-Authenticate":["NTLM"],"X-AspNet-Version":["4.0.30319"],"X-Powered-By":["ASP.NET"]} bei Microsoft.Activities.Hosting.Runtime.Subroutine.SubroutineChild.Execute(CodeActivityContext context) bei System.Activities.CodeActivity.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager) bei System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation)

All users that tried it have site-wide edit permissions.

I found that others have similar problems when the workflow contains email actions (e.g. this one). So I created a test list with two test workflows. The first workflow simply creates another element in the list. The second one creates an element and sends an email.

Both workflows fail with the same error when started by a non-administrator user.

Why are other users getting the access denied error? How can I resolve this error?

1 Answer 1


I have seen this before where users need to be added directly to the site (not through an AD group). Another method that allows the access is granting the NT Authority\Authenticated Users direct access, but may not be an option.

Others have stated that ensuring the OU that the groups you are using are actually scanned by UPS will fix this issue, but I haven't been able to test that in our environment yet due to the current configuration requirements.

There is a very good write-up here about the steps others have taken when this issue occurs.

My guess is if you add a user that is failing directly to the site and try again, it will work for them. You could also try ensuring that UPS is scanning the OU of your groups, but definitely check to see if the problem is fixed when adding the users directly (this however, is against recommended best practices, but sometimes is needed to make things work ;-/ .

  • Thanks. Directly adding the user works. I'll try to get the UPS working, too because managing user groups twice is not really a good idea. Jan 7, 2016 at 8:06

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.