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

PERMISSION GROUPS

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

 

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

I create a list for the department, thus:

 

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

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:

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

VERIFY RESULTS
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.

 

SUMMARY

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