A word about App Step in SharePoint 2013 Workflow Platform


I am sure most of us a familiar with App Step and that it is a mechanism provided to developers of SharePoint 2013-platform workflows (Designer workflows or Visual Studio workflows) to elevate permission of the workflow.  Just wanted to share this post to make it clear as to what we need to do when we grant permissions to workflow app (needed for app step to work).

I recently helped on a support case where customer had a scenario which I thought is very common in business process oriented scenarios which is where we would leverage workflows.  They had a list created with item-level security setup out of the box.  Here are the steps to do that.

  1. Create a list (use the custom list template).
  2. Go to list advanced settings.
  3. Under Item-level Permissions sections choose the radio buttons shown below.

1. Create a list (use the custom list template).

2. Go to list advanced settings.

3. Under Item-level Permissions sections choose the radio buttons as shown below.

image

4. Hit OK.

This will ensure that the item-level permissions are such that only the user that created an item in the list will be able to view and edit it.

Now create a SharePoint 2013-platform list workflow using SharePoint Designer 2013 that has a simple Log to History List action (as shown below) associated to the list created above.

image

Publish this workflow to the list that has item-level permissions.  Now, login to the site as a user who has contributor rights and create an item in the list created with item-level permissions.  Login to the site as a user with site owner (or site collection administrator) permission.  Go to the list and this user should be able to view the item created by the user with contributor permissions.  Now, start an instance of the workflow on this list item.

You’ll see that the workflow fails with the following error indicating that the list item was not found!

 

image

And on subsequent retry.

 

image

And in the ULS you will see the following entries.

05/11/2014 00:01:51.14    w3wp.exe (0x1690)    0x2550    SharePoint Foundation    CSOM    ahjq1    High    Exception occured in scope Microsoft.SharePoint.SPListItemEntityCollection.GetById. Exception=System.ArgumentException: Item does not exist. It may have been deleted by another user. ---> Microsoft.SharePoint.Client.ResourceNotFoundException: Item does not exist. It may have been deleted by another user.     --- End of inner exception stack trace ---     at Microsoft.SharePoint.SPListItemEntityCollection.GetById(Int32 itemId)     at Microsoft.SharePoint.ServerStub.SPListItemEntityCollectionServerStub.InvokeMethod(Object target, String methodName, ClientValueCollection xmlargs, ProxyContext proxyContext, Boolean& isVoid)     at Microsoft.SharePoint.Client.ServerStub.InvokeMethodWithMonitoredScope(Object target, String methodName, ClientValueCollection args, ProxyContext proxyContext, Boolean& isVoid)    3bc6edf8-52f2-f539-86c9-53679a403045
05/11/2014 00:01:51.14    w3wp.exe (0x1690)    0x2550    SharePoint Foundation    CSOM    agmjp    High    Original error: System.ArgumentException: Item does not exist. It may have been deleted by another user. ---> Microsoft.SharePoint.Client.ResourceNotFoundException: Item does not exist. It may have been deleted by another user.     --- End of inner exception stack trace ---     at Microsoft.SharePoint.SPListItemEntityCollection.GetById(Int32 itemId)     at Microsoft.SharePoint.ServerStub.SPListItemEntityCollectionServerStub.InvokeMethod(Object target, String methodName, ClientValueCollection xmlargs, ProxyContext proxyContext, Boolean& isVoid)     at Microsoft.SharePoint.Client.ServerStub.InvokeMethodWithMonitoredScope(Object target, String methodName, ClientValueCollection args, ProxyContext proxyContext, Boolean& isVoid)    3bc6edf8-52f2-f539-86c9-53679a403045
05/11/2014 00:01:51.14    w3wp.exe (0x1690)    0x2550    SharePoint Foundation    CSOM    agmjp    High    Original error: System.ArgumentException: Item does not exist. It may have been deleted by another user. ---> Microsoft.SharePoint.Client.ResourceNotFoundException: Item does not exist. It may have been deleted by another user.     --- End of inner exception stack trace ---     at Microsoft.SharePoint.SPListItemEntityCollection.GetById(Int32 itemId)     at Microsoft.SharePoint.ServerStub.SPListItemEntityCollectionServerStub.InvokeMethod(Object target, String methodName, ClientValueCollection xmlargs, ProxyContext proxyContext, Boolean& isVoid)     at Microsoft.SharePoint.Client.ServerStub.InvokeMethodWithMonitoredScope(Object target, String methodName, ClientValueCollection args, ProxyContext proxyContext, Boolean& isVoid)     at Microsoft.SharePoint.Client.Rest.RestRequestProcessor.InvokeMethod(Boolean mainRequestPath, Object value, ServerStub serverProxy, EdmParserNode node, Boolean resourceEndpoint, MethodInformation methodInfo, Boolean isExtensionMethod, Boolean isIndexerMethod)     at Microsoft.SharePoint.Client.Rest.RestRequestProcessor.GetObjectFromPathMember(Boolean mainRequestPath, String path, Object value, EdmParserNode node, Boolean resourceEndpoint, MethodInformation& methodInfo)     at Microsoft.SharePoint.Client.Rest.RestRequestProcessor.GetObjectFromPath(Boolean mainRequestPath, String path, String pathForErrorMessage)     at Microsoft.SharePoint.Client.Rest.RestRequestProcessor.Process()     at Microsoft.SharePoint.Client.Rest.RestRequestProcessor.ProcessRequest()    3bc6edf8-52f2-f539-86c9-53679a403045

Clearly this is one of the many scenarios where you’ll use an App Step.

So I first enabled workflows to use app permissions by following the steps outlined in the articles reference above (for convenience, I’ve replicated it here: Create a workflow with elevated permissions by using the SharePoint 2013 Workflow platform) and then granted full control permission to workflow (steps: also provided in the same article).

And then comes the part where I had to grant permission to an app.  The referenced MSDN article suggested to change the Scope attribute to the actual SharePoint 2013 site URLBut that did not work.  If I provide the permissions request XML with Scope parameter set to my site URL like:

<AppPermissionRequests>
    <AppPermissionRequest Scope="http://[servername]:[port]/sites/wftest" Right="FullControl" />
</AppPermissionRequests>

I still see the same error telling me that the workflow cannot find the list item to execute on if I set the Scope parameter to my own site collection URL.

It looks like the permission request XML should just be as what’s shown in the below screenshot for the app step to work correctly.

image

If you have developed SharePoint Apps, the permission request XML is the same as the app permissions we specify in the app manifest.xml file.

Once that is done, I hit the create button in /_layouts/15/appinv.aspx page and I am asked if I trust the workflow.

image

I “Trust It”.

I then changed my SharePoint Designer 2013 workflow design as shown below and Publish it.  When publishing I am shown this warning, since I am fully aware what this workflow is going to do, I hit the OK button.

image

 

After this when I invoke the workflow as a site owner (or site collection administrator) on the item-level permission enabled list on a list item created by another user, the workflow completed w/out problems.

HTH!

Comments (5)

  1. Ali Robertson says:

    Thanks for posting. I have exactly this issue in a similar situation. I am creating workflow tasks (based on a custom content type) secured by changing the workflow task list to use item-level permissions, then attempting to look up the information through the ID of the created task an app step (after approval). I was hoping that this would solve my problem, but after trying it I am still getting 404 errors (if I copy/paste the URL into chrome, I get the right XML – so it's definitely still a permissions problem)… I guess I'll try a 2010 interop and see how that goes.

  2. Anonymous says:

    Hello,

    I created a SPD workflow with a rest call to read a list from parent site. This works fine on my dev site. When I save my dev site as template and then create a new site the rest call throws Unauthorized error.

    What have i tried:

    – Adding app step in my dev site and changed the scope to be sitecollection. Created new template and then new site. Same error.

    – In new site manually added the permission request xml. This works but it means that the site admin needs to conduct this manually for each new site. Not ideal.

    Do you how can I get this to work without manually adding the permission request?

    thanks in advance,

  3. Anonymous says:

    At the end of your instructions, you state:

    "After this when I invoke the workflow as a site owner (or site collection administrator) on the item-level permission enabled list on a list item created by another user, the workflow completed w/out problems."

    In my scenario the person creating the list item where the workflow needs to run is a user with contribute level permissions. The workflow automatically kicks off when an item is created and immediately suspends despite the fact that the actions are in an app step.

    For this to work, is it a requirement that the person creating the item be, at a minimum, a site owner?

  4. tracy.sterling@gmail.com says:

    Any tips on how to relate the Workflow to its App Client ID?  We have multiple workflows in this environment and they are all called 'Workflow' when looking at the Site App Permissions.

    Thanks!

    -Tracy

  5. Morten says:

    @Deborah

    Be sure to check that the users has contribute permissions to the hidden list called "Workflow History" (Assuming you have not changed this in the workflow). By default this requires at least contribute permission on site level.

    You can find the hidden list in SP designer by navigating to "All files" then choose "Lists" right click "Workflow History" and choose properties.

    It might not be the reason, but though I'd pitch in 🙂

    //M