lock

The lock tag prevents respondents from going back to previous survey questions and changing their responses. By using survey navigation buttons, Go Form, Go Question, or other means, it is possible to move both forwards and backwards through a survey. This means that it is possible to change answers to earlier questions, and for survey variables to re-punch with different values. This can be useful for testing, but in general, while a survey is fielding, the back button is hidden and actual survey takers are discouraged from going backwards through the survey. Overwhelmingly, survey takers do not attempt to go backwards. The only strong incentive for doing so would be to change answers to screening questions if they are screened out. In Open Survey Mode, IntelliSurvey does allow this to happen. If singlepage is used in set defaults, the back button will not be available in respondents' browsers and the need for the lock tag disappears.

That said, there are situations wherein going backwards and changing the answers to prior questions can have a dire effect on survey programming logic/routing. In such cases, it is possible to prevent respondents from editing past responses, or from re-punching survey variables. This is accomplished by using the lock tag.

Syntax

The lock tag accepts a 'y' (yes) or 'n' (no) input. The default behavior if the tag is not present is lock: n, allowing variables to be re-punched.

VAR. Survey variable
type: radio
selectby: condition
optsfrom: OPTSLIST
lock: y

Example

In the following survey code example, respondents are assigned to one of two paths through the survey at QPATH. Respondents aged 21 and over are eligible for either, and will be assigned to the path for which they stated a preference at Q1. All respondents under 21 are assigned to the WATER_PATH group.

1. Which do you prefer?
type: radio
1. Water
2. Wine

2. What is your age?
type: radio
1. Under 21
2. 21 or Over

PATH. Survey Path
type: radio
selectby: weight, condition
1. Water Path {if anyChecked($Q2,1,2) } {weight: anyChecked($Q1,1)*100}
2. Wine Path  {if anyChecked($Q2,2) }   {weight: anyChecked($Q1,2)*100}

startgroup: WATER_PATH
condition: anyChecked($QPATH,1)
 
3. What water brands do you like?
type: radio
1. Dasini
2. San Pellegrino

endgroup: WATER_PATH

startgroup: BRAND_DEEP_DIVE
condition: anyChecked($Q3,1,2)

Brand Questions Here

endgroup: BRAND_DEEP_DIVE

startgroup: WINE_PATH
condition: anyChecked($QPATH,2)

Wine Questions Here

endgroup: WINE_PATH

Survey Continues Here 

It is likely that Survey Programmers (SPs) and testers will start test records and provide answers, and then go backwards and change those answers to test the outcome. The problem that arises is that these test conditions allow for otherwise impossible combinations of responses, and so may cause the appearance of programming errors when in fact there are none.

For example, suppose that a tester qualified for the water group by selecting option '1' at Q2, and provided an answer at Q3. Then, this tester decides to go back and qualify for the wine path by selecting option '2' at Q2. In this case, he/she will expect to see the wine questions. However, the next question the tester will see will be the deep dive of water brands, because the record still has data at Q3.

Placement on a selectby variable

To avoid confusion, it is simpler to put a lock tag on QPATH.

See demo See code Restart demo

In this case, it would also be imperative to communicate to all testing parties that once a record is assigned a path, it cannot be re-assigned to a different path.