@info – The practical side of SharePoint

Service Requests and Sensitivity

Posted by sharepoinTony on January 25, 2010

I recently implemented a customized version of the Microsoft Help Desk template for SharePoint 2007.  Quickly after launching I adjusted things based on feedback and input that never came prior to the launch.


The service request system, implemented via the help desk template, by default requires that all employees have access to submit requests.  The open-nature of SharePoint (and most IT departments) also dictates that users be able to see the pending service requests.  This visibility is normally thought of as a good thing for IT and helps promote self-service internally.  One of the customizations that I put in place was a notification workflow that sent email to the help desk staff telling them of newly submitted requests.  This workflow also automatically responded to the customer via email providing confirmation that their submission was successful.  The email provides a link back to the service request list so the customer could see all of the pending requests, including their own.

The Request

One significant post-launch request came from Human Resources.  They occassionally make requests that are sensitive in nature, such as terminations.  HR felt that those requests should not be visible to all employees.  This posed a problem for the service request list.  There is no doubt that it is a valid request, and the desire to keep most requests visible to users hadn’t changed, so I now had an exception to deal with.
Options considered were limited for various reasons.  One option would be to simply make a duplicate request list for sensitive HR requests.  But that meant managing two lists for the help desk, tracking two lists worth of requests for IT management, and created a possibility that a request might sit un-noticed.
Another option was to avoid using the service request list for all sensitive requests.  HR could send an email request as they had done historically in this small company.  Everyone was already “comfortable” with that process, however no improvements would easily fit into the old email process.  Reverting back to an old process just didn’t sound good unless there wasn’t a better solution.

The Solution

The solution concept chosen was to install a CodePlex feature that would allow a workflow to change the permissions on specific requests.
The concept was that sensitive requests could easily be identified since HR knew at the time of submission whether or not the request was sensitive, and could simply ‘mark’ the request as sensitive.  The workflow could check the column used for this purpose and based on its value could change permissions on that specific item.  We could limit the visibility to the appropriate staff without significantly changing the existing service request system.

The “Useful SPD Workflow Activities” feature from CodePlex was installed on a test server and the concept was examined closer.  After successful examination and testing it was decided that this would provide a very acceptable solution to the situation, and a quick response to the request from HR.
I created a new workflow to manage these permissions changes for two reasons.  First, I like keeping workflows as simple as possible.  Second, I wanted to be able to provide the flexibility to execute this behavior without sending emails that may be confusing which might come from adding these steps into the existing notification workflow.
The new workflow is very simple.  I check the designated column in the service request list and if it indicates that the item is sensitive then I remove a SharePoint Group’s permissions to the list item. I use several SP Groups to provide access, one contains all users, one contains appropriate HR staff, and one contains help desk staff.  When I remove all permissions from the group containing all users then only the members of the HR and Help Desk groups can see the item in the service request list.  There is no impact to other users or other requests.

Because the workflow can be started manually, we have the flexibility to “hide” any request that comes in by simply modifying the designated field and initiating the workflow.  This means that if HR forgets to “flag” a request, or if any other request is deemed sensitive we can quickly and easily “fix” it without having a workflow running all the time to monitor changes to requests.  Everyone is happy with this solution and it took longer to write this blog post than it did to implement in production.
Footnote: This CodePlex feature was installed and implemented on a 64-bit Windows Server 2008 system running MOSS 2007.

Sorry, the comment form is closed at this time.

%d bloggers like this: