Handling Permissions in Workflows

Set item permissions

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).

Pros

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.

Cons

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.

Run as Workflow Owner

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.

Pros

Saves using the Set item permissions action and doesn’t impact on the item level permissions of the item the workflow is running on

Cons

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.

Call web service

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.

Pros

Do not have to worry about the permissions that the initiator may have to perform the insert or update required.

Cons

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.  