Hi,
We want to set up the following workflow and wonder whether this is possible with LimeSurvey. The context is asking experts about local regulations in their home countries. For 50 countries, there will be 50 experts, 50 peer-reviewers, 1 supervisor.

Workflow:
1. ask experts to answer a set of questions (one expert by country)
2. for each country, ask a reviewer to read the answers, to say whether they would give the same answer (and if not, what answer they would give), and to provide comment
3. allow experts who answered at step 1 to change their answer (and ideally add new comments)

The supervisor should be able to make comments as well at step 2 and 3.
Thank you very much!
Mayeul

You can "Allow update responses with one token" - www.limesurvey.org/manual/Survey_settings#Tokens

Hi tpartner,
Thank you for the hint.
Should a respondent change his answers, is the history of the various answers saved (versioning)? Is it possible to see the old answers (before the changes made by the respondent)?

In any case, from what I read, I do not think it is enough for what I need.
The manual page you pointed to says:
"Allow multiple responses or update responses with one token?: Default: No . If you activate this setting the participants may return to his survey by clicking the invitation link, even if he already submitted the survey. If survey is anonymous or Enable token-based response persistence is set to NO, this adds a new responses. If survey is not anonymous and Enable token-based response persistence is Yes, user update existing responses. "
This means the same respondent can modify the answer. What I need is another respondent (called "reviewer") to comment on the first respondent answers, possibly suggesting a different answer.
The output would be like this:
Question Q1
Expert E1: Answer Q1version1 with comments
Later:
Reviewer R1: Answer Q1version2 with comments (saying he disagrees with E1)
Later:
Expert E2: Answer Q1version3 with comments (modifying his answer to take into account the comments made by Reviewer R1).

Thanks again.
Best regards,
Mayeul

If what I need is not directly possible, comments on the possible workaround are welome:

Once the answers from step 1 have been given, I make an export of the answer, then tweak the dump file (maybe with R or sed/perl or bash...) to create a new survey (one for each country) that I import again. Would possibly require many mouse clicks though... (the new surveys will be different for each country as they ll contain the answers from step one for each country).

Best,
Mayeul

There is no such thing as versioning in LimeSurvey. With my solution everyone with a given token would be modifying the same response case.

Thank you Tony

Two other possible work-around are as follows:

One might be to utilize a series of 3 different surveys, and employ token attributes to convey previous entries.

* Survey 1: Collects answers from Expert E1.
* Then export the answers and import them into the token table for Survey 2.
* Survey 2: Displays the responses from Survey 1 (from the token table), with new fields for Reviewer R1's comments.
* Then export the answers and import them into the token table for Survey 2.
* Survey 3: Displays the responses from Survey's 1 & 2 (from the token table), with new fields for Expert E2's comments.

And another possible workaround might be to set it all up on one single survey with a token attribute that specifies which generation survey a given record is, and with another attribute that ties them together, and with if-statement controlling the question display. That way you could keep going on for as many different version as needed. Of course to do that would require using the same attribute fields for each different version, so you'd need to setup a way to concatenate answers to all prior questions with the source spelled out.

Just a thought. Hope it helps.

Thank you for your answer, I think it will help a lot. I am currently reading LimeSurvey's documentation and I have installed a stack on my Linux box. I'll try the various suggestions mentioned here and will post here further questions or share the result if it works.
Mayeul

Hi,
Thanks both for your comments above. A few notes. I now understand much better the above answers, the token system and the type of branching it allows. The solution suggested above (to use tokens to decide for instance what should be shown and what should be editable) seems quite easy to implement, with a possibly needed precaution.
For a given country, the researcher, the reviewer and the supervisor will be working (one after the other) on one single instance of the set of answers. Hence, for 50 countries, there will be 50 set of answers, not 150. We can have a token which controls what a respondent will see (in a secure way, to avoid respondent trying to modify the URL parameters). However, the only potential problem I see with that is for the email notifications. We do want to send the first invitation to the researcher, and the second to the reviewer; while in the standard token table there is only one email address.

---

One way to solve this is to create custom token fields in the token table, with additional emails and names, hence having for each country only one record.
A record for a country would have the email field (standard in each limesurvey token table), plus 3 email fields, and a “step” field. The standard email field would the one to which the next email would be sent. A procedure will copy the relevant email from one of the 3 email fields to that standard email field.
This could be done simply by writing MySql triggers in the DB backend to monitor the content of the lime_tokens_xxxxx table. When the token is created, it is validated and (if OK) the email of the researcher is copied to the standard email field, and “1” is written in the “step” field. When the researchers has completed the survey, the MySql trigger writes the email of the reviewer to that standard email field, and “2” is written in the “step” field. This step field is used in the email templates to adjust the text which will be sent. Same thing for stage 3.

---

A quite different option is to have one record for each individual (so 150 records for 50 countries), with a token (eg country name or numerical code) to specify the country (ie the set of answers for that country), 3 people modifying in effect the same single survey at different times (so 3 people will have the same token). However, they would also have a code (as a field in the token table, sent to them by email) which would decide which questions to show and how to show them (previously answered questions being visible but not editable by the reviewer, the reviewer will say if they agree though).
In the simplistic form, the code would be the same for people have the same role (all researchers having the code “B27Ry”, all reviewers having “LD67Gz”). An improved code would be based on the respondent role and country, in a difficult to guess way, but easy to code with the expression manager. An encrypting function f(.,.) would transform f(country, role) into a code. Knowing the country, computing the code for both roles and comparing the results with the user provided code is enough to verify that a respondent is a researcher or a reviewer. To clarify thing: Fr-rv could be the code for France/reviewer and Fr-rs could be the code for researcher, but obviously some functions allow to hide such a simple process.
Also the code could be provided by URL to avoid having to ask the respondent to type it.
Last not least, one token field could be used by the supervisor to keep track of the step, and validate things for the next step.
Hope this might help someone else. Thanks for reading. Comments welcome!
Cheers,
Mayeul