App Step or Impersonation Step in SharePoint Designer 2013?
appstep

App Step or Impersonation Step in SharePoint Designer 2013?

Posted by on Thursday, April 10th, 2014  

 

I recently opened SharePoint Designer 2013 with the intent of creating a workflow using an Impersonation Step when I realized this option was missing. After some quick research, I discovered this workflow action had been deprecated in SharePoint Designer 2013. This article from MSDN explains why this action is no longer available for use on the SharePoint 2013 workflow platform, in addition to a list of all other actions that are no longer available. But not to worry! In SharePoint Designer 2013, you can choose the SharePoint 2010 Workflow platform during creation and still have all of those workflow actions available to you. Problem solved! End of blog. Just Kidding!

My intent of this blog is to use an example workflow scenario requiring elevated permissions, and walk through step by step how to implement this in SharePoint Designer 2013. I plan to use the new method, which requires you to wrap any actions in your workflow that require elevated permissions in an App Step. Why did I decide on the new method rather than using the Impersonation Step available with the SharePoint 2010 workflow platform? I will get into that as well. But first…

 

Why even use an App Step/Elevated Permissions for your Workflow?

 

A SharePoint Designer workflow will run under the permissions of the user who started the workflow. Certain steps of the workflow may require the user to have more permissions than you intend to grant them. If elevated permissions are not used, the workflow will not work, and you will likely receive an access denied error or the workflow will not execute at all. The use of an App Step resolves this issue. Any actions placed inside an App Step will have Read/Write permissions to all Items in the site, such as site lists (which I will use in my example scenario).

 

My Example Scenario

You would like users of your intranet site to fill out a form to submit a comment to the site owners. The users should NOT be allowed to view other user’s submitted comments.

 

Seems simple enough, right?

Well not exactly, although the solution I’m about to propose is actually quite easy.

The Issue

In order for user’s to be able to submit a comment, they will need to have Contribute permissions to the list, therefore allowing them to also see other user’s comments, which they should not be allowed to view.

 

Summary of the Solution

The solution will require the creation of two custom lists. One list will be the “public” list where users will submit their comments. The other will be a “security controlled” list that only site collection administrators/owners will have access to. We will then create a SharePoint Designer 2013 workflow associated with the public list and set it to start automatically when a list item is created. Once the user submits their comment, the workflow will create the list item in the security controlled list with the use of an App Step, and then delete the item from the public list.

 

The Solution Step by Step:

1)      Create two Custom Lists:

    • Comments
    • SecuredComments

 

2)      Break permission inheritance on the SecuredComments list and ensure only the needed users have permissions to this list. Make sure all other users have Contribute permissions to the Comments list to ensure they are able to submit the form.

 

3)      Create the columns in your lists. (Example: Name, Email, and Comment). I created an additional column called ‘Submitted By’ in my Secured Comments list. You’ll see why in a bit.

 

4)      If you would like to set your form up to open in a modal dialog from a button click, check out my previous blog explaining how to accomplish this with the use of the Script Editor Web Part: Don’t Script in the Wrong Web Part! 

 

5)      Next, you will need to activate the ‘Workflows can use app permissions’ feature in Site Collection Features to allow workflows to read from and write to all items in your site. Activation of this feature is necessary for the App Step to become available for use in SharePoint Designer 2013:

App Step or Impersonation Step in SharePoint Designer 2013?

 

6)      Create the workflow in SharePoint Designer 2013 associated with the Comments List. Be sure to select SharePoint 2013 workflow platform when setting up the workflow:

App Step or Impersonation Step in SharePoint Designer 2013?

 

 

7)      Set the workflow to start automatically when an item is created. You can change this setting in SharePoint Designer on the ‘View and manage settings for this workflow’ page:

App Step or Impersonation Step in SharePoint Designer 2013?

 

Workflow Creation Step by Step:

 

Step 1) Select App Step located in the Workflow Tab of the ribbon:

App Step or Impersonation Step in SharePoint Designer 2013?

Any actions you now place within this App Step can read from and write to all items in the site.

 

Step 2) Add an action within the App Step to ‘Create New List Item’ in the secured items list from the list item just submitted. Note: The action to ‘Copy List Item’ available on the SharePoint 2012 workflow platform is also no longer available for use. ‘Create New List Item’ is actually a better choice though since this allows us to map the ‘Created By’ field to the ‘Submitted By’ field in the Secured Comments List:

App Step or Impersonation Step in SharePoint Designer 2013?

 

The reason the ‘Submitted By’ field comes in handy is because this step of the workflow is running under the workflow app permission, therefore the ‘App Created By’ field of the entry in the Secured Comments list will show ‘Workflow’. By setting the ‘Submitted By’ field to ‘Created By’, we are easily able to capture the name of the user that submitted the new comment:

App Step or Impersonation Step in SharePoint Designer 2013?

Step 3) Add a step to delete the list item in the Comments List. Because the initiator does have access to the “Current Item” which is the Comments list, this action of the workflow could be taken out of the App Step and placed in a step of it’s own.

 

All that is left to do now is publish your workflow and test it out. Note that you will receive a message that states ‘By publishing this workflow, conditions and actions inside App Steps will run using only application credentials. Only continue if this is the intended behavior.’ Select OK.

The completed workflow:

App Step or Impersonation Step in SharePoint Designer 2013?

 

That’s really all there is to it. You can then simply setup an alert on your Secured Comments list to notify site owners when new comments are submitted. As you can see the workflow is very simple and easy to implement! I hope this helps someone out. I’ve googled this scenario several times and seem to find all kinds of suggestions to implement this, but to me this appears to be the most straight-forward and it works as expected. Please feel free to leave any comments.

 

I almost forgot! For anyone used to using the Impersonation Step on the SharePoint 2012 platform, I wanted to explain why I decided using the new App Step was the best choice.  The one drawback of using an Impersonation Step is that the workflow could suddenly stop working if anything were to happen to the user account that created and published the workflow. The purpose of the Impersonation Step is to run any actions inside this step as the user who authored the workflow. If the account that creates and publishes the workflow is edited in some way, possibly with a permission change on the site or a password change, then you have a broken workflow!

 

If choosing to use an Impersonation Step, you should always be sure to use an account specifically set up for this purpose. In addition to this issue is the fact that this action is now deprecated…likely a clue that building a workflow specifically for SharePoint 2013 is going to hang around longer than one built on the SharePoint 2012 platform. So in conclusion, when creating a workflow in SharePoint 2013 that requires elevated privileges, the App Step (which has read/write permissions to all items in the site) is a much better option and just as easy to implement. Thanks for reading!

Subscribe to RSS Feed

Sign Up for Newsletter

24

24

comments

    Jul 11
    2014

    Angela French

    I found your article and created a workflow using App Step. The second list is set to start a workflow when a new item is created. However the workflow doesn’t start when Created by the resulting SharePoint App. Am I missing something? I do have Workflow can use app permissions enabled under Site Settings. I hope you can post or send an answer.

    Reply
      Jul 15
      2014

      Jessica Criner

      Hi, this is actually default SharePoint behavior. Items that are created via workflow cannot trigger a workflow to kick off automatically. You should be able to verify this is what is happening by trying to kick off your workflow on your second list manually. Make sure you’re not logged in as the System Account and it should work. Also you can check in your logs and look for any error messages related to declarative workflows. What you might be able to do is merge your workflows together. Take a look at this link and see if it helps: http://summit7systems.com/workflow-interop-for-sharepoint-2013-to-the-rescue/. SharePoint Designer workflows have an action called ‘Start a List Workflow’. So basically what I’m suggesting is to try to trigger your second workflow from your initial workflow that created the item. Hopefully that makes sense and will work for your workflow scenario. Feel free to let me know more details of what you are needing to accomplish with your workflows and maybe I can help you out some more.

      Reply
        Jul 15
        2014

        Angela French

        But isn’t the entire point of the App Step to be able to do tasks like this?

        Reply
          Jul 15
          2014

          Jessica Criner

          SP Designer workflows will always run under the permissions of the user that initiated the workflow. The App Step allows you to run actions in your workflow that the initiator does not have access to do. To answer your next question, that is correct. Workflow Interop allows you to trigger a SharePoint 2010 workflow from within a SharePoint 2013 workflow. So your secondary workflow would need to be created on the SP 2010 workflow platform, which you should have available for use when you create a new workflow in SharePoint Designer 2013.

          Reply
        Jul 15
        2014

        Angela French

        I had tried the Start A List Workflow within the List A workflow, however it only allows you to select a 2010 workflow for some reason and my workflows are 2013 ones.

        Reply
    Jun 08
    2015

    Madhur

    Nice article on workaroaund SP2013 workflow running under system account

    Reply
      Jun 08
      2015

      Madhur

      but on Workflow ribbon I’m only seeing Impersonation Step not ‘App Step’.. Do I need to configure for this?

      Reply
        Nov 03
        2015

        Scott Marcus

        You probably chose a SharePoint 2010 Workflow when you were creating the workflow, rather than a SharePoint 2013 workflow. If you didn’t see a choice to use a SharePoint 2013 workflow, then you don’t have the SharePoint 2013 Workflow Manager installed in your farm.

        Reply
    Jun 08
    2015

    Madhur

    Now I’m able to see ‘App Steps’ but in disabled mode even though ‘Workflow can use App Settings’ enabled in site collection, not sure which step is missing

    Reply
      Oct 16
      2015

      Raj Bathulaaj

      check site features/site collection features, you will have one feature with workflow App. Activate it.

      Reply
        Nov 03
        2015

        Scott Marcus

        The feature is a Site Feature, not a Site Collection Feature.

        Reply
    Jun 30
    2015

    Rita

    Great article! It really helped me solve a requirement.

    Reply
    Jul 19
    2015

    Tracy

    I tried your process above, but the App Step commands would fail when I attempted to run the workflow as a non-admin user. It appears you also have to grant permission to app that gets created for workflows in the relevant app catalog, before those commands will work. See the following article: https://msdn.microsoft.com/en-us/library/jj822159.aspx.

    Reply
    Sep 17
    2015

    M Gaber

    thank you Jessica Criner, it was a greet article, I have been looking for any impersonation that can run my workflow for two weeks and finally I found your article, I created workflow using VS2012 so I used AppOnlySequence activity and the workflow finally triggered and run as expected, thank you agian

    Reply
    Oct 16
    2015

    Raj Bathulaaj

    Hi, If i put check out action in App step, which user account can be used to edit the document. currently it is showing SharePoint App. I thought who ever publishes the workflow in designer will be the owner of the workflow and hence check out in app step should be on his name.

    could you please help me out.

    Reply
    Oct 19
    2015

    fewlines4biju

    Very good article. Well explained… Liked it… impressed

    Reply
    Feb 03
    2016

    TalosP

    Hi – Is your solution an alternative to Add / Remove / Replace Permissions in a 2010 workflow?

    If so, what a FAFF! Having to make multiple lists, Forms and libraries just to copy a secure version of the file (the one you don’t want people to see) will create far more work for people. Perhaps knowing that this is the case would help before designing their site would help.

    I am a big, big fan of SharePoint and the easy to use Workflows but this change is a step back and forces us to use 2010 workflows.

    Reply
      Feb 03
      2016

      TalosP

      Your article is clear and concise btw.

      Reply
    May 16
    2016

    SPR

    Nice article :). Just wanted to know what is the basic difference between impersonation step and App step. What is the need to introduce App step when Impersonation step was already there? Could you please help.

    Reply
    May 17
    2016

    Cardinal Pipkin

    Hi SPR – The difference between App Step and Impersonation Step is that they are the same but the App Step loses the extra functionality, such as Add/Remove/Replace permissions. The App Step is only useful if you need to use update list item or create list item when an end user triggers a workflow. I’ve found that using an App Step helps solve errors in the workflow – these errors are typically caused by lack of permissions by an end user.
    The solution to the problem of lack of functionality in the App Step is to trigger a 2010 workflow. That’s the main reason they kept the 2010 wf’s in SPD to allow people to do that.

    Reply
      Aug 19
      2016

      suresh Chandhanam

      HI CARDINAL,

      Using App Step we can break/add permissions. For this you need to elevate workflow app permissions to ‘Full Control’ where as by default workflow app step has write permissions. Please check https://msdn.microsoft.com/en-us/library/office/jj822159.aspx this link for more information

      Reply
    Aug 19
    2016

    suresh Chandhanam

    Thanks for this post. It is giving good explanation and comparison between impersonation step and App step

    Reply

Leave a Reply