Gotcha on SharePoint Designer Workflows in App Step 26

Why write this post?

A colleague of mine at work came at me with a problem with one of his Workflows he was authoring in SharePoint Designer 2013 (SPD) against #SharePoint 2013 Server On Premises.  Now before you say “… well that is what you get for using SPD”, he had to use it because of the Client policy, i.e. No Visual Studio Solutions. So, what is the problem right… here is a summary of the email below.

Now, I think here would be the perfect place to say thanks to Jeremy Thake @jthake and Mauricio Ordonez at Microsoft who gave me a much better understanding of the process of how the XML that you use when Adding an App Step as described in this MSDN article here actually works. Now, Ive always used this at the Site Collection Level never in a Sub Web and Ive always targeted the “Current” web, you will see what this is important later on in the post. However, if you read the documentation  in the post as it talks about the XML needed for the App Permission and Scope, you are told to copy it as is.. which one does right 🙂 think im fibbing? Read the cautionary note.


Now the fact that I am doing this at the SC Level, and i see …/sitecollection/web and it works.. I “mistakenly” thought that this would work if I used it ‘unaltered’ in the Sub Web making a call to the Parent Web…And this is why you are here and still reading. so…

Observed Error

I have noticed an issue working with SharePoint Designer 2013 Workflows when you are in a Sub Web making calls to the Parent Web. A colleague of mine experienced this and I was able to replicate it, I wonder if anyone else has seen this and have any thoughts on the matter.

1. Open SPD 2013 targeting a Sub Web –

2. Make a HTTP Call Activity to the parent web

3. You get an Unauthorized as the response code coming back

What Works using SharePoint Designer 2013

What Does NOT work “with” or “without” using the App Step

What is striking is that I can make all these call outside of SharePoint by using Fiddler, CSOM, Managed Code etc. but that is not in the context of running inside SharePoint like a SPD Workflow… any thoughts?

Eventual Resolution

So there are two things going on here in this XML

   1: <AppPermissionRequests>

   2:     <AppPermissionRequest Scope="http://sharepoint/content/sitecollection/web" Right="FullControl" />

   3: </AppPermissionRequests>


First, Scope, which managed where you are targeting this App Step to work and Second, Rights, which tell the App Principal what it can do in that Scope.  Here is what I know to be TRUE after I have tested a few Scenarios

    • If you set the XML above to the below.. KEY Thing here.. the /web is gone from the Scope URI
   1: <AppPermissionRequests>

   2:     <AppPermissionRequest Scope="http://sharepoint/content/sitecollection" Right="FullControl" />

   3: </AppPermissionRequests>

  • You will be able to
  1. Open SPD in a Parent Site Collection and use a HTTP Call to Target the Parent SC and any Sub Web Beneath it
  2. Open SPD in a Sub Web and and use a HTTP Call to Target its Parent Site Collection Above it

What I HAVE tried and Still get a Unauthorized i.e. still don’t work

  1. Open SPD at any Level (Site Collection Parent or Sub Web) and use a HTTP Call to Target a “Different” Site Collection

But I understand why… let me break it down by the numbers

  1. When you open up SharePoint Designer and specify a URL anything you do is Scoped at that Level, however you can as in the case of Workflows use the “App Step” [which by the way only becomes an available option after you implement this MSDN article here ] you can use the Workflow App Principal and target other Levels.
  2. That’s the pickle isn’t it…
    1. When you do http://{hostname}/{catalog site}/_layouts/15/appinv.aspx to set up the XML Scope and Rights you are already tied to that Url arnt you? so…
    2. When you open up SharePoint Designer in another Web it DOES NOT KNOW about the App Principal Workflow of the one you did in a separate Site Collection or Site Collection/Sub Web ergo…
    3. you will Always get an Unauthorized

So.. that being said, let me show you a few screen shots with explanatory notes.


So I guess if one were to ask me what is going on I would say… “it seems that the URI in the scope is set to scope at the Level you specify and Look Downward and UP TO that level you scope it at”. Even though when I open SPD up at a Top Level Site Collection and have the XML URI scoped to /web I can see only that current Web even though it is a Site Collection FURTHER, if I am at a Sub Web in that Site Collection I can only see that Sub Web. If However I set the XML URI to scope at /sitecollection I can see the entire Site Collection and any Sub Web from anywhere in the SC.

Lets take a look at this procedurally to make it work as I did it.

First you need to follow the MSDN article here and below what you are seeing is


I’m targeting the Site App Permission in the Sub Web


I go through the entire thing of taking the App Principal GUID of the Worfklow and set my XML to be scoped to Scope=http://sharepoint/content/sitecollection/ Right=”FullControl” then I trust what I have just done.


Next I open up SPD, if you already have it open you will notice that your “App Step” is greyed out, you need to shut down SPD and re-open it for it to pick up the change. What you see below is the App Step Invoked from in my Sub Web (SPC14) and I have 2 “Regular Steps” inside my “App Step”

  1. Reading from the Parent Web and will Log out accordingly
  2. Reading from the current Sub Web and will Log out accordingly


Just showing you the Headers


Next showing you the HTTP Call to the Parent Web from within the SPD opened up Sub Web


Next showing you the call to the current Sub Web


Next this is the workflow as it was ran…




I sincerely hope that this helps you in your efforts. Im often reminded that “Everything is EASY once you know it!” I thought I “knew” this but there is always more to learn.


Cheers. & Irie.

Leave a comment

Your email address will not be published. Required fields are marked *

26 thoughts on “Gotcha on SharePoint Designer Workflows in App Step