Truly Anonymous Intranet Surveys
Many of you have probably had a great experience using SharePoint Surveys. If you are using SharePoint in an Intranet type environment, you have no doubt set up a survey in SharePoint for some reason or other. And quite often when organizations set up a survey, they’d like users to be able to respond anonymously. No problem you say – when you set up a survey in SharePoint you have the option to make it anonymous, right? Well technically you are correct. There are 2 primary ways you could achieve this:
- Create an anonymous web application for anonymous surveys
- Create “anonymous” surveys on authenticated web sites
Let’s explore the pros and cons of each of these approaches and find out just how anonymous they actually are.
Create an anonymous web application for anonymous surveys
Firstly let’s look at some possible reasons why you might want to consider this approach:
· You have an external facing site where users don’t log in.
· You have an internal web site and you want to be absolutely certain that user responses to a survey are 100% confidential and anonymous.
· You want to use only the out-of-box capabilities of the SharePoint survey module.
There are a number of blogs already out there on how to create an anonymous web application and site such as this one, as well as how to create a survey on an anonymous site such as this one, so I’m not going to repeat that right now (although later in this blog I’ll discuss this a bit more…). What I will do first though is highlight some drawbacks to this approach that I’d like discuss further:
· Multiple page surveys don’t work on an anonymous site
· Anonymous users can’t save progress
· Intranet sites are typically not anonymous
Multiple page surveys don’t work on an anonymous site
So what exactly does this mean? Well typically longer surveys will contain multiple pages and / or branching logic. In SharePoint when you respond to a survey that has multiple pages, SharePoint automatically saves the state of the survey when you move from one page to the next. It does this so that in case you lose connectivity while completing a long survey, you’ll be able to continue where you left off. It doesn’t really matter whether there might be better ways to implement this; the fact is that SharePoint writes the work-in-progress survey to the survey list when you move to another page in the survey. The problem is that SharePoint cannot write the incomplete survey to the list unless it can associate that survey with a particular user. If the user cannot log in at the point when they move to the next page, they won’t be able to continue with the survey.
Anonymous users can’t save progress
So if the user is not logged in (i.e. anonymous) SharePoint will automatically request the user credentials. If the user is using IE (Internet Explorer) and the web site is in the Intranet zone, IE will by default automatically send through the user’s domain credentials and the user will be logged in. Alternatively the user will be prompted for credentials and if they don’t enter these credentials, they will be presented with an unauthorized dialog box:
If the user does log in, they will then move from the NewForm.aspx page to the EditForm.aspx page with the survey id as one of the query string parameters (e.g. …/EditForm.aspx?ID6&…). Since the survey is now in edit mode as opposed to new item mode, it stands to reason SharePoint needs to have the user context in order to retrieve that specific survey and to ensure the user can’t retrieve anyone else’s. The Create responses and edit responses that were created by the user setting on the Advanced Settings page of the survey has no mean unless the user is logged in:
Thus is you want to edit the partially complete survey at this point, you simply have to be logged in.
Intranet sites are typically not anonymous
Another caveat is that Intranet sites are almost always not anonymous. To get around this you could set up a separate web site specifically for surveys where users could connect anonymously. This would entail something along these lines:
Create a new web application that supports Windows Authenticated users for survey administrators (e.g. https://survey.admin). This would normally be created in the Default zone. Create a top level site collection and grant specific permissions to the Survey Administrators so they are able to create new surveys on this site. You could further grant other permissions as necessary to any other users that may need to view survey responses or perform other actions on the site.
Extend the web application to another zone / IIS web site (e.g. to the Intranet zone on the https://survey site). Grant access to anonymous users for this zone, and remove access for Windows Authenticated users.
This will prevent users from being able to log into the https://survey web site using their Windows credentials, but survey administrators will still be able to log into the https://survey.admin web site to manage content as this is in a different zone.
Of course you still won’t be able to have multiple page surveys, but users will never be able to log into this site (https://survey) either accidently or automatically.
This method is the same approach you would typically take on an Internet facing site.
You could further enhance the user experience to create the perception of having multiple pages by incorporating some clever JavaScript / jQuery and css to show and hide sections on the survey as a user progresses through it. This would likely mean editing the NewForm.aspx page in SharePoint Designer for the specific survey you wanted to do this on. You’d then have to repeat the process for future surveys you wanted this functionality on.
Create “anonymous” surveys on authenticated web sites
So we’ve explored the first option to create an anonymous web application for surveys. This approach might work for you in many scenarios, but it may not be a viable option in other cases. Let look at an example:
Your organization, LitwareInc, decide to set up your company’s Annual Satisfaction Survey on the https://intranet site.
· The survey is quite long, say 50 questions.
· You need it to have some branching logic to probe people further when they respond in a certain way to some questions.
· It needs to have paging so as not to put people off by presenting too many questions at once.
· You want your employees to be able to save progress and to be able come back later to complete the survey because you realise your employees are busy and they may not be able to work through everything in one session.
· You really want your employees to feel like their responses will be treated with confidentiality and will be completely anonymous, i.e. have no fear of repercussions from their responses because their manager found out what they were saying about them.
So your HR representative creates the survey as follows:
· They create a new survey called “2011 Annual Satisfaction Survey”
· Create 10 pages of questions with some branching as needed
· Specify “No” in the survey General Settings to Show user names and “No” to Allow multiple responses.
· In the survey advanced settings (Item-level permissions) the survey administrator ensures users can only read and edit their own responses as follows:
So let’s see what happens after a couple of users have completed this survey.
Surveys completed by logged in users are not truly anonymous
When the survey administrator sets up a survey, they have the option on the survey general settings page (Title, Description and Navigation) to specify whether user names appear in the survey results.
If they select No here, users could understandably be under the impression that their response was anonymous. As they work through a multiple-page survey, which they have to be logged on in order to do this, their user name is replaced by three asterisks ***
And in fact even when multiple users complete the survey and the survey administrator views all the responses, the survey results still appear to be anonymous:
However if the survey administrator simply goes in and changes the survey General Settings to show the user names again…
… guess what happens the survey administrator (or anyone else who has permissions to view all responses) now see when they look at the survey responses page:
So while your users might have thought nobody would ever have been able to find out what their specific response to the survey was this isn’t actually the case.
How to make a not-so-anonymous survey anonymous
The fact is that even though you specified that user names should not be shown in the survey results doesn’t mean they aren’t actually stored in the system. Furthermore the user names can easily be made visible again by simply changing an option on the settings page of the survey by the survey administrator. So what options do you have?
· Accept this and trust your survey administrators to respect the privacy of the survey users.
· Hack the SQL database tables, find the survey and remove the created by and modified by user id – this is a DEFINITE NO-NO.
· Use the SharePoint API (object model) to set the Created By and Modified By columns to another user account.
If you’re happy with the first option above, then you don’t need to read further. Fantastic! If you’re even considering the second option than you shouldn’t be using SharePoint and I’m glad you’re not working at any of my customers. And if you’re still reading than hopefully I can give you some good advice!
You can do almost anything in SharePoint using the SharePoint API. And since using the API is supported, writing your own code to modify content is perfectly acceptable (as long as you write proper code of course and understand what you’re doing). So if we wanted to write some code to address this problem, what options could you consider? The ones I came up with are as follows:
· Use a custom Workflow
· Write a custom workflow action in Visual Studio that sets the Created By field to a specific user.
· Create a custom workflow in SharePoint Designer that fires whenever a survey is submitted (when the Completed field is set to “Yes”).
· Have an elevated task that calls your new custom workflow action for that survey list item. When the Created By column is updated for that survey item, the Modified By field will also automatically be updated (to the elevated system account user).
· Write a custom Event Receiver feature
· This might be scoped at the “Web” level and apply to all Survey type lists. Alternatively you’d need to implement another way to link it to specific lists on the site to trigger on.
· The event receiver would fire whenever a "Completed" survey is submitted on any Survey list on the site.
· The feature will set the Created By and Modified By columns for the submitted survey to the "System" account.
· Use PowerShell
· Firstly let me reference another blog where I found some guidance on doing this for lists in general: Updating the “Created By” and “Modified By” Columns in SharePoint lists using POWERSHELL
· Now I’ll share my implementation of this, specifically for this survey requirement:
# ===================================================================
#
# Brian's awesome script to make surveys anonymous
#
# ===================================================================
Add-PsSnapin Microsoft.SharePoint.PowerShell
# Specify the site collection URL
set-variable -option constant -name url -value "https://survey"
# Specify the name of the survey list
set-variable -option constant -name surveylist -value "AnnualSurvey"
$web = Get-SPWeb $url
$list = $web.Lists[$surveylist]
$listItemCollection = $list.Items
$genericAuthor = New-Object Microsoft.SharePoint.SPFieldUserValue `
($web,$web.CurrentUser.ID,$web.CurrentUser.LoginName)
foreach ($listItem in $listItemCollection)
{
$listItem["Author"]=$genericAuthor; $listItem.Update();
}
$web.Update()
$web.Dispose()
· And this is how the list of responses I showed early looks now:
Note how all the Created By column values are set to the context of the account the PowerShell script was running under (in this case svc_spinstall).
· You could either run this PowerShell script on demand or schedule this to run as frequently as needed. You should fully test this in a development environment first and possibly add error checking and do some performance optimization as needed. This is of course my standard necessary disclaimer!
No solution is perfect
It is important to note that it is unlikely that you will ever find a solution that is perfect for all scenarios. In in the final solution I proposed above, there may still be shortcomings for you. For example once the user name is unlinked from the completed survey, the user will be able to complete the survey again since there is no longer anything in the system linking them to this survey. Additionally, partially complete surveys will still have the user name associated to the survey – the onus is on the user working through the survey to complete it. Furthermore, I’m sure many of you could point out other examples of why these options may not work for you. In those scenarios perhaps InfoPath would be a better solution since this can give you much better control, although this would likely also have an associated increase in complexity. However hopefully this blog does at least give you some direction on what things you might need to consider and some possible workarounds. Happy surveying!