I'm trying to create subsites for items in a project list using a SharePoint Designer Workflow using the SharePoint REST API services, but each time I attempt to run the workflow I get the Response

"Unauthorized" (or sometimes a 401 or 403 error... I've tried a lot of fixes).

I am running the workflow and assigning permissions all using the administrator account so I don't think it's a user privileges error, but an issue with the app privileges. I know the app step was working (some of the time) because I have received emails from the workflow. I've tried so many different versions though that it's hard to tell if it's working at this point.

The subsites will be created under the projects site collection:


which is of course the same address that the HTML POST call references...

but I have tried to add app permissions to the main site collection as well, just in case that could be an issue:


I have looked through many of the resources available and tried everything I can think of:

Microsoft say they updated the XML permissions code sometime at the end of 2017: https://msdn.microsoft.com/en-us/library/office/jj822159.aspx

allowapppolicy 2017 update

but I've tried copy pasting the code there and even trying to bypass the gotcha with the following XML:

<AppPermissionRequests AllowAppOnlyPolicy="true">
     <AppPermissionRequest Scope="http://sharepoint/content/sitecollection/web" Right="FullControl" />
     <AppPermissionRequest Scope="http://sharepoint/content/sitecollection" Right="FullControl" />

but nothing seems to be working.

Could this be an issue with the app catalogue, or is there something I'm missing? Alternatively it could just be that Microsoft Products are garbage, but I need to check whether it's my fault first.

I'd appreciate any sort of assistance (but please don't mark as duplicate question and link to some irrelevant article).

  • have you tried enabling the Site feature "Workflows can use app permissions" Jan 18, 2018 at 12:30
  • Yes. That is required to create an app step in spdesigner.
    – J. Doe
    Jan 18, 2018 at 12:45
  • Have you check that full control user are able to create new site from SharePoint UI or Not? Jan 19, 2018 at 20:01
  • Yes. For both the Root site collection and the projects site collection https://contoso.sharepoint.com/ & https://contoso.sharepoint.com/sites/projects/
    – J. Doe
    Jan 22, 2018 at 8:00
  • You may have somewhere permission issue. Run the Process Monitor from sysInternals and check set the filter for result contains 'Denied' to see if you are blocked from some resources (temp folder, or some registry entries) Jan 23, 2018 at 16:13

2 Answers 2



So, after a bunch of back and forth I managed to get a working version of this workflow running. I have placed an image of the workflow and it's parameters so that others whom might have hassles may benefit.

Create SubSite From List Workflow

My workflow generates a subsite based on an existing list item but anyone should easily be able to swap out those variables.

Of course to run this workflow you would still have to go through the required steps:

Step 1 Enabling the Site feature "Workflows can use app permissions" (App step would otherwise be greyed out in sharepoint designer)

Step 2 Scrape the Site Template (Google will help you here)

Step 3 Set your workflow permissions - I tried different versions of this code but this is the only version I got to work...

Navigate to your app permissions page https://contoso.sharepoint.com/sites/collection/_layouts/15/appinv.aspx

Lookup Workflow ID Site>Site Settings>App Permissions (It's the number between | & @) (You may need to have a saved workflow to see this)

Insert the following code and trust the app:

<AppPermissionRequests AllowAppOnlyPolicy="true">
 <AppPermissionRequest Scope="http://sharepoint/content/sitecollection/web" Right="FullControl" />
 <AppPermissionRequest Scope="http://sharepoint/content/sitecollection" Right="FullControl" />


It's also important to note the correct URL for the api call (And remember that it's a POST call when creating the workflow)

I tried a bunch of different ones (along with streams of other attempts at workarounds) but the only one I got to work was:

[%Variable: RequestURL%]/_api/web/webinfos/add

which is equivalent to


I hope this helps someone else from losing hair...

  • If all the nested dictionary stuff is what ended up being your major headache, something I like to do is have the workflow email me the dictionary (in the body) when I'm troubleshooting, so I can see exactly how the request is getting formatted. Then I can work out the web service issues outside of WF, and then fix the nested parameters/dictionaries in WF after I get them working from normal service calls.
    – Chris Romp
    Jan 24, 2018 at 0:46
  • It seems that the error response codes are a bit vague, misleading or just not all that valuable. After updating the <AppPermissionRequests AllowAppOnlyPolicy="true"> (which I think was the initial problem) I gave myself the run around and it seems that the 401 is more of an actions not permitted than a user permissions error in this case... So I think it's like a runtime error actually. So just rebuilding the workflow and having the correct URL worked eventually. But sending yourself reports throughout the lifecycle of the workflow is a very good idea!
    – J. Doe
    Jan 24, 2018 at 11:16
  • The response codes are simple, yes, but you can also take the response body and response headers, and put them into an email to yourself from workflow as a diagnostics tool (you can't log dictionaries to the history list, unfortunately). Even putting the request headers and body into an email to yourself will let you troubleshoot the actual requests from javascript (since the dictionaries are basically just JSON objects).
    – Chris Romp
    Jan 24, 2018 at 17:03

Even with the permissions and the app step, you need to include the digest token in your HTTP action. Are you first POSTing to _api/contextinfo to get a token from inside of the app step, then including the token (from d/GetContextWebInformation/FormDigestValue in the response) in your HTTP action's X-RequestDigest header?

To get a little bit more info about the error, you can take the response dictionary (and headers) and email it to yourself from inside of workflow. That might shed some light on the issue. Also, a little more detail on how your workflow is set up would be helpful to troubleshoot this.

enter image description here

  • I will post an update, but I don't see that you need digest tokens with a trusted app in all of the material I had referenced perviously?
    – J. Doe
    Jan 23, 2018 at 20:27
  • I guess that's more for list updates? ¯\_(ツ)_/¯
    – Chris Romp
    Jan 24, 2018 at 0:47

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.