I appear to come across the same scenario time and time again. A request of some sort is made. It goes through one or multiple lines of approval. Whilst it is in the approval process the item is set to read only so that no amendments can be made while it is in review. Upon final approval, the item/document is updated to reflect the approved/rejected status. The permissions on the item at that point do not allow for this update. Or upon approval an item is added to another list that the “initiator” does not have access to contribute to. So I thought I would discuss the different options that can be used for dealing with permissions inside a workflow:
This action allows you as the workflow designer to decide to inherit or create unique permissions on the current item on which the workflow is running. This works well in state machine workflows where the permissions at each state need to change (i.e. the current approver needs the ability to update an item whilst everyone else only has read access). You can choose to inherit the permissions from the parent or stop inheriting as well as choosing to keep or delete any current item permissions (i.e. when someone needs adding to the permissions at a certain point).
I like this action because you can define exactly which roles/people/groups can have access to an item at any given time during the workflow process.
If a workflow fails for whatever reason the permissions stay at the most recent set item permissions action.
It is difficult to control permissions to lists when the items have item level permissions.
The action set action allows us to choose a configuration option of “Run as workflow owner”. This means that all actions inside the action set container will run under the permissions of the account which published the running workflow. This is a great workaround when you know that you have God-like permissions to do everything on your farm and don’t want to give any users access to certain lists of libraries.
Saves using the Set item permissions action and doesn’t impact on the item level permissions of the item the workflow is running on
This doesn’t work inside a state machine workflow; only a sequential workflow. So if you are running a large process that you have designed with a state machine where the final approval means an item update, you cannot access the “Run as workflow owner” checkbox inside action set when it is placed on a state machine branch.
Created By and Modified By are always the same person for all instances of the workflow. When running as workflow owner the credentials of the person who published the workflow are used. This means that any items created or updated are effectively done by that person so you cannot quickly see who ran the workflow in the first place (and if you work in a blame culture, you will find people quickly asking you why you updated or modified an item!!).
If the workflow publisher leaves then the credentials and permissions will no longer work.
An alternative way to deal with inserting and updating items without giving the initiator access to do so is to use web service calls which can run as a specified account. As long as the account the web service is using has the permissions to perform the actions you are asking of it then there are no worries around who the initiator is and what permissions they may have.
Do not have to worry about the permissions that the initiator may have to perform the insert or update required.
A lot trickier to configure to achieve the same result. I find that the Call web service action quite tiresome (because I don’t use it very often) so have to read up on what services and methods to use and spend a lot of time testing.
Again, if the account that the web service is using becomes locked out or deleted then the workflow will fail.
There are a lot of options for dealing with permissions in workflow. I lean more heavily to the Set item permissions action although it doesn’t sit comfortably with me. I would be really interested to hear your approaches here so please leave some comments and I may well revisit and update this blog post with your best practices.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.