Creative Commons License


« Silverlight - merging detached object back to the attached data context | Main | Windows Live Messenger wave 4 - freaks me out »

SharePoint 2010 - Configuring List Item Permissions with Workflow

The client had a pretty "simple" situation where:

  1. We want to create a Request list where different people in the company can add requests, but assign it to a department.
  2. Once created, only members in that department has access to this request item


You can use Active Directory groups here as well.  Here are my four security groups




I plan to use re-usable workflows later to configure the list item permissions.  So I need to create a few site columns, here's the first one DepartmentGroup.  This is basically a People or Groups field.


I create a list for the department, thus:




Here's the second site column.  This is a lookup column to the Department list.  I'm bringing over the ID field as an additional field.


Add a few records:




Stop inheriting permissions from parent (site), and do a bit of house cleaning and remove the unnecessary groups.



The idea of the workflow is that:

  1. Whenever an item is updated
  2. Look up the group based on the selected Department (via the additional ID field)
  3. Assign item-level security to the list item
  4. Remove permissions to modify the item, and grant the department group permission to view and modify that request.

Create a re-usable workflow.  Target any content type.

We'll need the lookup site column, so associate that


The permissions steps need to be run as impersonated steps.  The impersonated steps can not be mixed with the normal steps (such as Step 1)


Remove (unused) Step 1, and add "Replace permission" action


Start with the second parameter which is the easier one.  Click on "this list" and select Current Item



Click on "these permissions" and we want Contribute and Read permissions


Click on "Choose" and set who we'll be granting Contribute/Read to


Select "Workflow Lookup for a User…" and click Add
We want to do a look up on the Department list.


The field we want is DepartmentGroup (our Person and Group site column).  Return the field as Login Name
Set the filter Field below to ID


Set the filter Value field to Current Item.Department:ID

(You can also use the DepartmentLookup field here, just return it as Integer)


Final result:


OK everything.  Remember to save and publish



Go back to SharePoint list

Configure the workflow and make sure it runs when a list item is created or modified


Check the permission of our first request (before the workflow)


It is inheriting from list.  Nothing special.



Create a new request for our Network department - see the workflow has completed


Check its permissions


"NetworkHeroes" has been assigned "Contribute" and "Read" permissions to the list item - everyone else has been stripped out.
The List Item has also stopped inheriting permissions from the parent list.



So the solution works and is relatively elegant.  Though the client mocks me and says it was so much more easier in Lotus Notes :-(

The following features in SharePoint 2010 makes this example a little bit cleaner than with SharePoint 2007:

  • "Additional Fields"
  • Impersonation Step
  • Re-usable Workflows
  • Replace Permissions Action

Reader Comments (15)

This is simply fantastic. Thank you . I was looking to do the same thing and this was just what I needed. I especially loved the associate column tip.

October 11, 2010 | Unregistered CommenterJoeH

Hi, I have tried your workflow and everything works fine when I insert an item but when I modify an existing one i get this error:
SharePoint Exception: Coercion Failed: Input cannot be null for this coercion.

The only difference with your exemple is that I have associete the workflow with my list and I have a second field (people and group) for read only permission.

I realy can't understand what's wrong... can you help me?

November 8, 2010 | Unregistered CommenterAshry

That error most likely means that your ID is null. Converting null to INT or User will give you that error.

November 9, 2010 | Registered CommenterJohnLiu.NET

Hey John,

Thanks for the post. I've continued to be challenged by using the impersonation actions when in need of including multiple people (users or groups). The problem is when you are picking those people/groups up from a variable. The impersonation actions seem to choke. Have you seen the actions work successfully with multiple people/groups being specified in a variable that is then used in the impersonation action definition?

January 20, 2011 | Unregistered CommenterRuss Edelman

I can give it a go later, but I would try my hardest to avoid storing multiple person in one variable. Is it possible to lookup the person/group when you need it?

January 24, 2011 | Registered CommenterJohnLiu.NET

Hi JohnLiu.NET.

This solution works great for me, but when i try to give it a go with two or more values it would only give me the first one!

Another issue is that i want multiple instances for the request list. Like, giving permissons to read to certain users and to other users, that are specified by the user in that list, permissons to contribute.

Thak you in advance,


November 5, 2011 | Unregistered CommenterZel

If you want to add multiple permissions, don't use Replace Permission action - this action removes all existing permissions.

November 9, 2011 | Registered CommenterJohnLiu.NET

Hi John!

Thanks for the post! Do you have any suggestions how this could be applied to assigning permissions to multiple AD groups at once?

I have a default SharePoint blog post list, where I have multiple items with individual permissions. Ideally, I'm looking for a way to control multiple item permissions at once, but in this case it doesn't seem to be possible with OOTB SharePoint features. Anyway, your solution would still provide much needed ease for the administrative tasks if it could be applied for multiple AD groups at once.

November 16, 2011 | Unregistered CommenterThomas

The Replace Item permission action supports multiple "users'. Essentially, in that dialog you can add multiple entries for each AD group and assign them different permissions.
e.g. say for different departments

IT : Contributor
Finance: Reader

November 16, 2011 | Registered CommenterJohnLiu.NET

Thanks for the reply John!

Just to be sure if I understood correctly. So, in my case, I have several "user permission cases" and each of these cases consists of multiple AD groups. For example:

Case A (AD group 1, AD group 2)
Case B (AD group 3, AD group 4)

If I want to assign read permission for particular item to Case A, would this mean that I must have individual workflows for different cases or could this be done by having just one workflow using conditions, while in the new item form, the item creator could have a drop-down list with Case A and Case B as alternatives?


November 16, 2011 | Unregistered CommenterThomas

I mean this:

1 workflow with 1 workflow activity

November 17, 2011 | Registered CommenterJohnLiu.NET

When I add a new item or edit existing items. I get this error, "Coercion Failed: Unable to transform the input lookup data into the requested type."
BUT, when I manually run the workflow on an item. It works.

You mention that it is because ID is null. I put a history log before and after the Impersonation Step to see the current ID value and Lookup ID value.

When i manually run the workflow, History log shows ID value the same and everything works.
When I add a new item or edit existing items, I get the same error, but it wont even show the log before Impersonation step...

I tried putting a pause before and after the Impersonation step in thinking it needs time to grab the ID. Nope.

I dont know what is going on. Help? =D

Thank you.

August 9, 2012 | Unregistered CommenterDavid

John mention that its due to ID is NULL

When using lookup field in workflow, SP return NULL on currentLookupID when I create or edit item, but will have a value when manually running the workflow. Don’t know why….

Gives me this error [Coercion Failed: Unable to transform the input lookup data into the requested type.]

First save DepartmentLookup:ID in Request list as a variable.
Then the step where you "Set the filter Value field to Current Item.Department:ID", Set filter Value field to the variable instead.

I got it to work this way.

Thanks Jon.

August 10, 2012 | Unregistered CommenterDavid

I'm glad you got this to work.

I'm thinking that the variable can be NULL or empty string. And by forcing it into a variable first you convert the type, and after that the workflow action was able to handle empty strings.

August 10, 2012 | Registered CommenterJohnLiu.NET

John, thank you for this post.

I got another "simple" situation here.
I have a "request user access to services" list workflow. When a request access to services is created, the workflow:

If item was created by UserB
>>>> set Variable::IsItemApproved = Yes
>>>> start approval process (custom infopath form) in Current Item with UserA

If Variable::IsItemApproved = Yes
>>>> Assign [custom infopath form to complete task] to UserC

The point is about permissions: the only user who can access the task item (infopath forms to approve or complete) is the creator of the "request user access to services" item.
And I can't figure out what I am missing. Can you give any directions on it?

Thank you.

December 15, 2012 | Unregistered CommenterEgidio

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>