I thought I'd write this up for anyone who has a request to create an anonymous whistle-blower-type submission form created using SharePoint 2010 (this would probably work the same for 2013). It's not 100% fool-proof but it's as close as you can get without Visual Studio which was a requirement.
I feel others may have a similar situation since I've been asked to do this a few times now so I thought I'd write this up. This is for anyone who is asked to have an anonymous whistle-blower submission form created using SharePoint 2010 or 2013. The criteria they specified was:
- They wanted the form to not have any user identify-able information displayed to ANYONE.
- This included the users who review the submissions.
- They wanted the submitted items not to be seen by anyone after they were submitted.
- They did not want custom code used but SP Designer workflows were okay.
- This meant no Visual Studio event receiver.
The easiest way I could think of is to have a Drop List where users can submit their item, create a workflow that moves the item to a more secure list, and delete the item from the Drop List. However, there are some inherent problems with this solution:
- The Created By and Modified By fields are set to the user who submits the item. This is not something you can change in SharePoint using OOB functionality. When deleted, it still shows who originally created the source item in the recycle bin.
- When deleted, the item's title is also shown. If the submitter puts identifiable information in there like a person's name, that can be problematic
The approach I used to get this done is 3 phased:
- Create the source & destination lists
- If you already have the source list created, save it as a template and create another one using that template
- On the destination list, break inheritance and set security appropriately
- SharePoint 2010 Workflow
- Create a new SharePoint 2010 list workflow on the Drop\Source list that runs on item creation
- Create an Impersonation step
- This is necessary because the user won't have rights to create an item in the destination list.
- Change the TITLE field of the item to something generic
- You can choose static text or build a submission number variable
- This is so when it's deleted, the title field in the Recycle Bin is non-descriptive and non-identifiable
- Create a new item in the secure list using the source item
- Use the "Create Item" action in the action dropdown
- Make sure to add all of the fields from the source list and match them to the corresponding fields in the destination list
- Delete the item in the source list
- If someone tries to be slick and restore an item from the recycle bin, the workflow is run on item creation so it will run on it again and just delete it again.
- However, this is a problem because when it goes to the recycle bin, Collection Administrators can see who created it…enter Phase 2…
- 1-Time PowerShell Script, Run On BOTH Lists
- PowerShell has become a staple of SharePoint administration and advanced functionality and a necessary skillset in any SharePoint administrator's arsenal. I've written a number of PowerShell command-lets and scripts that have made my job so much easier including creating a SharePoint Visio SiteMap of an environment, setting version counts on all libraries and cleaning old versions, document inventories looking for modified dates to find archive candidates (not published yet), as well as exporting exhaustive document level permissions (not published yet).
- In this scenario, there is a property of all lists called "ShowUser" that is not exposed through SharePoint's UI (except in the case of surveys). When this is enabled, it turns the Created By and Modified By user names into asterisks (*****) and when the item is deleted, it still masks the fields in the recycle bin. Here's the quick and easy script:
#Get Web and List objects
$web = Get-SPWeb http://SharePointWebApp/sites/MySiteCollection
$list = $web.Lists["ListName"]
#Disable username from appearing in item dialogs
$list.ShowUser = $false
#Dispose of Web object
- You now have a drop list that doesn't keep a document longer than it takes to run the workflow so it's anonymous submission
- You have a destination list that is secured to a select set of viewers who also cannot see the user identifiable information (unless they put it in the metadata which we cannot help). It also doesn't show the created and modified by usernames and since we used impersonation, it would just be the workflow creator account.
- The recycle bin is secured because it too doesn't show a possibly descriptive title and the user who created the item.
Some might be thinking, "What about users who can run the PowerShell script, they'd be able to switch it back so you can see the users." Yes, there's no 100% perfect solution (even with Visual Studio), but given the parameters and restrictions, this is the best solution I've come up with. Even a Visual Studio event receiver can be disabled or re-coded and republished. If something can be done, it's likely it can be undone too but minimizing the options is the name of the game.