Your LimeSurvey version: LimeSurvey Community Edition Version 6.15.5+250724 
Own server or LimeSurvey hosting: Own server
==================

Hello! I have a question about the best way to approach my problem. I would like to have one survey where the access to the responses can be limited based on the answer to a question in the survey. For example: question 1 would be "Which person would you like to send this survey to?", followed by a bootstrap dropdown where you can select a name.

Ideally I would like to grant a user access to a specific set of responses in a survey, configured so that user "John Doe"can only view responses where in question 1 the answer "John Doe" was selected. It appears this is not possible within Limesurvey, correct? Therefor I have come up with a few alternate solutions. What would be the best implementation?

Option 1: do not use the admin interface
The first option is to simply not add readers to the admin interface but instead use the built in reporting (the detailed admin notification) which sends the responses to e-mail. I've figured out that I could use ExpressionScript to determinate which e-mail the notification should be sent to based on the answer to a question. The downside of this option is that it would eliminate the useful features from the admin panel, such as bulk exporting and/or filtering.

Option 2: link multiple surveys together
The second option I am investigating is to split up the survey into multiple seperate surveys. The first survey would just contain question 1. Based on the answer to this question the "End URL" parameter would change and redirect the respondent to the a second survey specifically marked as "Survey John Doe". Each person that should have access would get their own seperate survey (even though the survey contents would be identical). This would allow me to grant individual users access to the responses of their specific survey without disclosing responses directed to other people.

This option seems the best, however it does have the downside of splitting up the database. If possible, I would like to be able to have one big database where all the answers could be viewed. A second downside is that in the future we might want to use an API to allow responses to be entered into the database. This seems more difficult if I split it up into multiple surveys.

Does anyone have any advice, tips and/or tricks? Am I on the right track or am I overthinking? Thanks in advance for the advice .

jochemh99 wrote:

Ideally I would like to grant a user access to a specific set of responses in a survey, configured so that user "John Doe"can only view responses where in question 1 the answer "John Doe" was selected. It appears this is not possible within Limesurvey, correct? Therefor I have come up with a few alternate solutions. What would be the best implementation?

I don't think that you can limit the questions that a admin user can see within a survey. Either they can see all of it, or none of it. Limiting this to a subset of questions is not possible, I think.

Option 1: do not use the admin interface
The first option is to simply not add readers to the admin interface but instead use the built in reporting (the detailed admin notification) which sends the responses to e-mail. I've figured out that I could use ExpressionScript to determinate which e-mail the notification should be sent to based on the answer to a question. The downside of this option is that it would eliminate the useful features from the admin panel, such as bulk exporting and/or filtering.

Correct. The admin emails can also be styled and configured with ExpressionScript and made "nicer", but you will always only have the answers of a specific respondent.

Option 2: link multiple surveys together
The second option I am investigating is to split up the survey into multiple seperate surveys. The first survey would just contain question 1. Based on the answer to this question the "End URL" parameter would change and redirect the respondent to the a second survey specifically marked as "Survey John Doe". Each person that should have access would get their own seperate survey (even though the survey contents would be identical). This would allow me to grant individual users access to the responses of their specific survey without disclosing responses directed to other people.

If you want to use the backend for exporting responses to CSV/Excel/SPSS, etc this would be the way to go. Depending on your environment and setup you might be able to skip the first survey or you could just provide a "normal" webpage with links to the different surveys for each person, but yes, the initial survey with one questions and the end url redirect will work as well.

This option seems the best, however it does have the downside of splitting up the database. If possible, I would like to be able to have one big database where all the answers could be viewed. A second downside is that in the future we might want to use an API to allow responses to be entered into the database. This seems more difficult if I split it up into multiple surveys.

Correct, if you have different surveys, you will have different databases and you won't be able to see those responses all together from within Limesurvey. Regarding the API, you would have to access each survey/database seperately.

Does anyone have any advice, tips and/or tricks? Am I on the right track or am I overthinking? Thanks in advance for the advice .

You will need to see what is more important to you: The access for each admin user to the backend, or having everything in one database.

What you could think of is having one big survey with respondent choosing who they are answering about and then send a report to the respective user. Then you could create a weekly/monthly process via API/Cronjob that downloads the responses for each user and sends it to them on a regular basis. This way they have the results on a regular basis within a CSV/excel file or similar, but receive the single responses immediately. Or you could create individual dashboards (outside of Limesurvey) for them to access.