When automating business processes in SharePoint, there are often requirements that involve either restricting or accessing content in a list or library. Workflows run using the permissions of the person initiating the workflow which sometimes can cause issues if it is trying to write to a list/library that the user doesn’t have access to. Also, there may be requirements where at certain stages in a workflow the permissions of an item change. A common example of this is an approval process where different people should have the ability to edit at certain review phases but only be able to read at others. To be able to update permissions the person initiating the workflow would need full control permissions, which obviously you don’t want your end users to have.
SharePoint Designer 2010 provided workflow developers the functionality to bypass this issue using what is called Impersonation Step. The impersonation step can be added to a workflow to grant the user initiating it the permissions of the person who published the workflow. This becomes a problem when the person who published the workflow leaves the organization or company and their access is removed from the SharePoint site. The workflows using the impersonation steps that they published will FAIL! This can be mitigated by using a service account to publish workflows with impersonation steps that has full control and never gets removed.
SharePoint Designer 2013 does not include the Impersonation Step, but there are way that you can add a SharePoint 2010 Impersonation Step into your 2013 workflow. In the 2013 version the App Step was added, which allows you to add a step to a workflow giving the user read/write permissions to any SharePoint list or library involved in that step of the workflow. A site feature needs to be enabled for the App Step to be available. The big benefit of the App Step is that it does not use the permissions of the person who published the workflow therefore you never have an issue if that person’s permissions are removed. A major drawback of the App Step compared to the Impersonation step, however, is that you can not change the permissions of the item. This does not make it a viable option for the approval process that gives different people access at different steps of the process or any process that requires the permissions of the item to change. Below you can see the difference in List Actions available.