The client had a pretty "simple" situation 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
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:
REMOVE LIST PERMISSIONS
Stop inheriting permissions from parent (site), and do a bit of house cleaning and remove the unnecessary groups.
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.
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)
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