Problems

When making the move to the cloud one of the biggest challenges for developers is how to accomplish tasks that used to be fairly simple, for instance using workflows to perform elevated actions. Recently I came across one of these instances. I had a client that we had setup in Office365 over a year ago and since that time several applications have been created. One of these applications was a time off request form. When this was setup it wasn’t brought up that they wanted to limit who could see the requests. We setup a solution where we broke the inheritance of the request after it was created. We only had an admin level account so full testing didn’t happen in this instance. We released the update and apparently it was communicated to another developer that it wasn’t working and instead of fixing the problem they just commented out the permissions section.

Fast forward a few months later and an audit was performed and it was identified that anyone could see the requests. Needless to say I was surprised. In investigating resolutions for this problem I kept slamming into the wall of user permissions. After giving myself a headache I came across a solution that made things rather simple. First, let me say there are ways of getting past this problem if you are working within an Add-in/App but in this instance we were dealing with an applications loaded directly onto the page so we didn’t have an Add-in/App context to switch to. So the user creating the request didn’t have ‘manage permissions’ permission and so could not break inheritance like we needed.

Initial Setup and Permissions

Starting in SharePoint 2013, so this solution is not limited to Office365, there is an option where you can enable a feature on a site which allows Workflows to use “App Permissions”.  To find this feature go to site settings, and Manage Site Features. At the bottom of the list of features there is this guy, “Workflows can use App Permissions”.

The description says to allow workflows to read from and write to all items in this site, but that is not all that we can do. Let me start by saying that in order for this feature to activate properly you need to be in Office365 or have Add-ins/apps configured in your on-premise environment. If you do not and try and activate this feature it will tell to check to make sure a couple services are configured. You need to have SharePoint 2013 workflows configured as well.

If you activate this feature, you are not presented with much fanfare but as long as there are no errors and the feature shows as active then you are good to proceed. From here workflows can use app permissions but we need to grant some permissions to do what we need. Keep in mind that whatever permissions are granted to workflows in this site are available to every workflow running in this site.

Back on the site settings page under Users and Permissions we can find the option for Site App Permissions.

This page allows us to remove permissions from any app that may have been granted in the site. Our first step will not be to remove any permissions but we do need to get the ID of the workflow app for this site. If everything activated properly you should see an entry similar to this one.

The part we care about is the part between the last | and the @ symbol. This is the ID of the workflow app for this site. Copy this value and store it, we will need it for the next step. From here we need to navigate to the “Grant Permission to an App Page. This page can be found by going to the following URL.

http(s)://{hostname}/{workflow site}/_layouts/15/AppInv.aspx

Where hostname is the domain to access your SharePoint environment and workflow site is the path to the site that will host the workflow. Your page should look something like this.

Take the workflow app ID that we gathered previously and put in the App Id text box. Then hit lookup, this will fill the information in the next three boxes.

Now we just need the permission request XML. This is some XML that tells SharePoint what permissions we are granting. The easiest way to get this XML if you want something other than full control is to create a SharePoint Add-in/App in Visual Studio and use the app.manifest to generate the XML. For this example we will be granting Full Control to our Workflow on the list we want to work with. The XML to do that is:

<AppPermissionRequest Scope=”http://sharepoint/content/sitecollection/web/list” Right=”FullControl” />

</AppPermissionRequests>

If we paste this into the Permission Request XML box and click create we will be asked which list we are granting permissions to and whether we trust the app or not. After selecting the list and clicking Trust we are good to start creating our workflow.

Creating the Workflow

To create the workflow, we are going to use SharePoint Designer. Open SharePoint Designer and connect to the site where you granted the permissions. Create a new SharePoint 2013 list workflow.

Once inside your workflow we need to add an App Step. The App Step is circled in the image below. If the options is disabled then Designer is not recognizing that the feature has been activated.

Once this has been added any actions that we add to this app step will have whatever permissions we have granted plus read and write to all lists in the site. So for example we could add a “Call HTTP Web Service” action and this call will be issued in the context of the workflow App. When we publish this workflow we will get an warning message reminding us to make sure we want to run with app permissions.

Click OK on this dialog and the workflow will publish and we are good to go.

Conclusion

As you can see we can now perform any action that is available to us through REST calls and thus we can automate almost any process. Whether it is managing permissions or creating sites. Have fun experimenting with this new ability.

About the Author: 
Ryan Schouten has been working with SharePoint since December of 2006. He has had experience with all versions of SharePoint from 2003 to 2013. Ryan is a Microsoft Certified Trainer and has several certifications from Microsoft from SharePoint 2010-2013 and Office 365. Before starting on SharePoint development Ryan was an experienced ASP.Net developer specializing in server and client side interactions. This experience made transitioning to SharePoint a lot easier.

Follow Ryan on Twitter: @ShrPntKnight