I'm working on a SharePoint Workflow as a proof of concept for one of our clients. The requirements are that it must be accomplished as a SharePoint 2013 workflow with no custom code, created only in Designer.

I created a List workflow with custom Approvers and Processors defined in separate lists, as suggested by Brij Dammani in this article. The workflow is working quite well - except there is no security at all; anyone with edit rights can edit the Workflow Tasks list no matter to whom the task is assigned, and complete their task and advance the workflow.

From my searches there are two main suggestions to add security. One to use a second SharePoint 2010 workflow, which uses the deprecated Set Item Permissions action, to lock down the list item to the person whose task it is. The second is to roll my own/import a custom SharePoint 2013 action to manipulate the permissions. Obviously both of these break the requirements. My own idea (a messy one) is to have the workflow move items to the lists with the correct permissions. As my Approvers are set dynamically via a list this makes maintenance difficult.

My question is:
What is the preferred way of managing permissions in SharePoint 2013 Workflows?

Surely there must be a way to lock down the tasks to the person to whom it is assigned without having to use deprecated actions or custom code??

3 Answers 3


I've looked into this a lot and I think I can answer the original question. It is my understanding that SharePoint 2013 has removed impersonation in favour of using the new App Step. The idea behind this is to create a virtual app that represents workflows, then to give permissions to this virtual app. The short version of how to do this is below, Microsoft themselves explain here.

  • First, activate the feature on the site by going to Site Settings > Site Features and set the feature "Workflows can use app permissions" to Active.

  • Next, go to Site Settings > Site App Permissions. There should be a virtual app named "Workflow" there. Copy the client section of the App Identifier - this first Guid, between "|" and "@"

  • Grant permission to the app by going to http://{hostname}/{catalog site}/_layouts/15/appinv.aspx. Paste the App Id, click Lookup. Then paste the following verbatim into the Permission Request XML. There are no placeholders in the Scope value above. It is a literal value. Enter it exactly as it appears here.:

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

  • Click Create then Trust It to trust the app. Now, anything running inside an App Step will have FullControl permissions.

This doesn't actually help me lock down the tasks, as there is no custom action that can set the item permission on the task list. To do exactly what I want, I need a custom action that can set item permissions. Still, it's good to know that it's not possible OOTB.

Also noteworthy, as a workaround I tried creating two lists, two workflows (one on each list) with two different task lists, with different permissions. The idea being that the one workflow would create an item in the second list, kicking off the second workflow. The users would then only be able to approve those items in their own task list. However this did not work. List items created by workflows do not kick off that list's workflow as explained in this msdn article: 2013 Workflow not triggered on item created with a workflow. Nor can a SP2013 workflow start another SP2013 workflow with OOTB actions. An SP2013 workflow can only start an SP2010 workflow.

I've come to the conclusion that what I'm trying to do is impossible in SP2013 workflows OOTB. If anyone can correct me I'd be very appreciative.

  • Really late to comment. Somehow this post caught my attention just now. Did you try to create a designer workflow using SharePoint 2010 platform? In SP 2013 you can still create 2010 workflows and the impersonation step is available in those workflows
    – Unnie
    Feb 11, 2016 at 15:06

If you want to restrict the users to have permission in only their tasks(ie Assigned to me), you have to use SharePoint 2010 workflow and replace permission on that item to allow only Assigned user edit rights on that item. Choose SharePoint 2010 workflow platform while creating workflow , if you are trying this in a SharePoint 2013 site.

Another workaround is to edit all the views in the Task list and filter to show only those items which has Assigned column value = [Me]. But if the users have rights to edit the views they can override this settings or create new view to see other's items.

Edit: Disdavantage using SP 2010 workflow is that it runs under the privilege of the user who created the workflow.So it can break if user privileges are lowered or user left the company.

  • Thanks Unnie - Ok, so there is no way to do this with a SharePoint 2013 workflow? I did add the filter, as was suggested in the original article to which I linked. However, you can still click through to that task by opening the list item and clicking the task under Tasks. I expect there are many other ways to get to a task to edit it if it is merely hidden, so merely hiding it is not adequate security.
    – 08Dc91wk
    Aug 21, 2014 at 12:46
  • No basically SP 2013 workflows does not have impersonation step. So you cannot do this in 2013 workflows
    – Unnie
    Aug 21, 2014 at 12:57
  • Thanks Unnie, wow that seems like a serious step backwards - if we can't manage permissions without custom code we're going to struggle to convince our client to use SP 2013 workflows. I will look into creating a 2010 workflow with SPD2013, the option to do so isn't immediately obvious...
    – 08Dc91wk
    Aug 21, 2014 at 13:02
  • Unnie is correct. It's not an elegant solution, but it'll work most of the time. You have to have some sort of trust in the users. The fact is if they cause malfeasance, it's auditable. If you can't accomplish the same functionality, it may also be worth looking at third party workflow products as they can easily achieve your requirements.
    – SkinnyE
    Feb 11, 2016 at 14:38

We can also use "If" actions to evaluate who is the currently logged on user and compare that with the item and then allow or disallow updates.

  • 1
    Thanks Joy - the task is edited/approved as a list item though, so I think this needs to be done as a permission. The problem is that after the task is assigned, anyone with edit rights may complete the task. There doesn't seem to be an action for the workflow to disallow access to edit the list item for users who are not the assigned approver.
    – 08Dc91wk
    Aug 21, 2014 at 12:50

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.