I had a pretty "simple" requirement from the client where:
- We want to create a Request list where different people in the company can add requests, but assign it to a department.
- 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 matching each department.
Figure 1: 4 different security groups
Department Lookup List
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.
Figure 2: Site Column for people and groups
I create a list for the department, thus:
Figure 3: Departments Lookup list
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. This is using SharePoint 2010’s additional fields capability.
Figure 4: ID as Additional field
Add a few records:
Figure 5: Creating a new item in my request list
Figure 6: See the Department:ID
Remove List Permissions
By default, at this point my Request list would be inheriting permissions from parent site. So first stop inheriting permissions from parent, and do a bit of house cleaning and remove the unnecessary groups to keep it simple.
Remember if you are not the site administrator, don’t remove your own permissions otherwise you lose ability to modify the list!
Let's Work on that Workflow
The idea of the workflow is that:
- Whenever an item is updated
- Look up the group based on the selected Department (via the additional ID field)
- Assign item-level security to the list item
- Remove permissions to modify the item, and grant the department group permission to view and modify that request.
Let’s get started. First create a re-usable workflow. Target any content type.
We'll need the lookup site column, so associate that. This uses SharePoint 2010’s reusable workflows.
Figure 7: Associate just a site column in SP2010 reusable workflow
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). This is a new workflow capability in SharePoint 2010.
Figure 8: Create an impersonation step
Remove (unused) Step 1, and add "Replace permission" action. This workflow action is only available within an impersonation step.
Figure 9: Add replace permission workflow
Start with the second parameter which is the easier one. Click on "this list" and select Current Item
Figure 10: Select current list item
Figure 11: Replace permissions on the current list item
Click on "these permissions" and we want Contribute and Read permissions
Figure 12: Add permissions
Click on "Choose" and set who we'll be granting Contribute/Read to
Figure 13: Select the user - use workflow lookup
Select "Workflow Lookup for a User…" and click Add
We want to do a look up on the Department list.
Figure 14: Lookup from the departments 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
Figure 15: lookup permission group
Set the filter Value field to Current Item.Department:ID
(You can also use the DepartmentLookup field here, just return it as Integer)
Figure 16: Select department:ID from current item
Figure 17: Check everything
OK everything. Remember to save and publish
Figure 18: Save and publish
Go back to SharePoint list
Configure the workflow and make sure it runs when a list item is created or modified
Figure 19: Workflow settings
Check the permission of our first request (before we build the workflow)
Figure 20: Old item before workflow
It is inheriting from list. This is really nothing special.
Figure 21: inheriting from list
Create a new request for our Network department - see the workflow has completed
Figure 22: Create a new request and check workflow 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.
The following features in SharePoint 2010 make this example a little bit cleaner (or possible) than with SharePoint 2007:
- "Additional Fields"
- Impersonation Step
- Re-usable Workflows
- Replace Permissions Action