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 URL.  But that did not work.  If I provide the permissions request XML with Scope parameter set to my site URL like:

 <AppPermissionRequests>
     <AppPermissionRequest Scope="https://[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!