Recently I was asked to create an anonymous survey in SharePoint. In many ways these are fairly annoying because SharePoint really wants to know who you are when you’re on the site, so you have to be careful about what features you utilize in your anonymous sites. However, I think I’ve found a pretty straight forward way of addressing the issue as long as the company is comfortable with creating a separate web application that only allows anonymous access and doesn’t try to authenticate. This site should only be used to house items that they want to have as anonymous access, so I tend to “portal” the functionality from the anonymous web app inside something like an intranet if needed.
First step is to create an anonymous web application for anonymous surveys. There are several reasons for wanting to use 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.
However, realize that being anonymous does come with some drawbacks:
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
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 (defeating the purpose of being anonymous). 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:
If 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. http://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 http://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 http://survey web site using their Windows credentials, but survey administrators will still be able to log into the http://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 (http://survey) either accidently or automatically.
This method is the same approach you would typically take on an Internet facing site.
Once you have created the anonymous only web application, the next step is to create a survey like you normally would, remembering that features like branching logic will not work.
After the survey has been created, you’re still not completely done. You have to apply a little anonymous permissions magic in order to allow for anonymous users to actually contribute to the survey and fill it out…
Set advanced settings
On this screen, we set ‘Read Access’ to ‘All Responses’, ‘Edit Access’ to ‘Only their own’ and ‘Allow items from this survey to appear in search results’ to ‘No’. Setting read access to ‘All Responses’ seems a bit weird. After all, you will normally not want your anonymous users to see the responses of all other users. We will change this back later, but for some reason, it is necessary to select this option here.
Next we go to the permissions screen:
The survey by default inherits the permissions from the site, but for anonymous surveys this will not do. By selecting ‘Edit Permissions’ from the ‘Actions’ menu, you can specify specific permissions for this survey.
The Setting menu has now appeared and from it, we choose ‘Anonymous Access’.
In this screen, make sure that the check boxes for ‘Add’ and ‘View’ are selected.
Set advanced settings again
If this is alright, we can go back to the ‘Advanced settings’ screen to set Read Access back to ‘Only their own’.
There, you’re set. The survey can be filled out by all anonymous users, but they cannot see each others entries. The information entered in these forms will be stored in the survey’s library and you can inspect each entry or view aggregated graphs of all entries. So what happened here? We first set the ‘Read Access’ to ‘All Responses’, because only then can we set the Anonymous Access settings (all check boxes will be greyed out otherwise). But after setting the permissions, we can safely turn access to all responses off again. This procedure is a bit odd, but it works.