Starting in Version 1.92, all navigation and branching is controlled by Expression Manager (EM). You can still use the Conditions Editor as described below. However, internally, Expression Manager converts the Conditions to a relevance equation. LimeSurvey only reads the relevance equations during survey-taking, thereby eliminating the need for multiple database reads against the conditions table.
However, you do not need to use the Conditions editor. If you prefer, you can hand type relevance equations, using qcode naming.
Everything you can do in the Conditions editor is forward-compatible with relevance equations. However, EM gives you access to over a hundred functions and mathematical and logical operators, so you can create complex relevance equations that could never be back-ported to the Conditions editor.
You can design logical branching with LimeSurvey, this means that you can decide that some questions will be displayed only if some conditions are met like "Show question X if question Y was answered 'Z'".
Our approach is to implement a Hide/Show Branching Logic:
This approach is different from the Jump Branching Logic that is sometimes implemented by other software. In the Jump Branching Logic, the resulting action of a met condition would be to jump to another question (that is to say hide all questions in between). LimeSurvey doesn't implement this Jump Branching Logic method. Instead if you wish to jump a series of questions, you would simply set the same condition on all the questions you do not wish displayed. For example if the jump condition you want to set on Question2 is "Jump to Question5 if the answer to Question1 is 'Yes'", you can simply:
Basically, a condition can compare values and returns true or false.
Values that can be compared are:
It is important at this point to understand what is considered as an eligible question-entry for the condition editor:
A question-entry is either:
As a matter of simplification, question-entries are just called "Question" in this document and the condition editor.
Several comparison operators are supported from the simple "equals", to the advanced "Regular Expression":
You can build complex conditions by combining simple conditions with the AND and OR logical operators.
However, it is important to understand that LimeSurvey automatically determines which logical operator to apply: this means that the use of the OR or AND operators is determined according to the context of the condition.
We'll talk about complex conditions later, but let's start by the simple ones first.
First you need to access the condition editor:
The following screen will appear:
An elementary condition is simply a single condition without any OR or AND logical operators.
It is composed by:
Detailed instructions on how to set up the above example can be found at this blog post: "Conditions based on token attributes"
As said earlier, LimeSurvey automatically decides which logical operator (AND or OR) should be applied between conditions depending on the 'context'.
Note also that the order in which you define your elementary conditions is not relevant as LimeSurvey will automatically reorder them according to its own logic.
Let's study this in detail.
When you have several conditions they are ORed together if they share the same tested value
When you have several conditions, they are ANDed together if they don't share the same tested values
Imagine you define the 3 following sets of conditions:
Note: This paragraph applies to Multiple options and Multiple options with comments questions, and not to Array Multiple Flexible (number) with checkbox layout questions (for this later question type, each checkbox is a separate question-entry and is not really handled as other multiple options question-types).
For Multiple options and Multiple options with comments questions, in the tested valuepart of the condition editor this question will appear in two flavors
And now let's test your knowledge of conditions by trying to answer this question:
Now the answers...
For Issue A:
For Issue B:
A scenario is simply a manual grouping of conditions in which conditions are evaluated independently of conditions from other scenarios. The complex condition resulting in this association of several scenarios will be met if only one scenario is met: in other words scenarios are logical grouping of conditions, respecting the above rules, and which are ORed together to build complex conditions.
All what we described above is true inside a scenario, and by default all new conditions are created inside the "Default Scenario".
However, when you create a new elementary condition, you decide to affect it to another scenario than the default one.
Scenarios are identified by a simple number, the "Default scenario" having number '1' as its identifier.
When you create (or edit) a condition, you can modify the scenario in which the condition is stored:
The number id of a scenario has no importance and different scenarios can have non-continuous ids.
First you access the condition editor:
The top part of the window always shows any conditions already set for this question:
In the example above question B is set to only display if:
The number id of a scenario has no importance and different scenarios can have non-continuous ids.
Click on the tab corresponding to the type of the tested value you want: it is either a previous question or a value taken from the profile of the participant (token attribute).
Note that in order to use the Token your survey must:
Then select the entry you want as tested value.
If you select a question-entry (from the 'Previous questions' tab) and if this question uses predefined answers then the corresponding predefined answers are displayed in the Predefined tab of the comparison value selection.
Several comparison operators can be used:
Select the tab that corresponds to the type of comparison value you need: it can be a predefined answers, a constant value, an answer from a previous question, a value from a token attribute, or a regular expression (reserved for the advanced regular expression operator).
Then select or type in the value you want to use.
Note that if you select a value in a tab, then change the tab and select another value in this other tab, the first option you selected is lost.
When using predefined answers, you can then select one or more predefined answers:
After that click on the "Add Condition" button.
Apart from adding new conditions, the Add/Edit can be used to
By clicking on the edit icon on a condition line, the edit condition form at the bottom is automatically displayed with the current settings for this condition. Note that in this mode you can only select one predefined answer.
Click the update condition button to update this condition.
As said above, scenario numbers have no impact in the way conditions are evaluated. However, modifying the scenario numbers are needed in order to:
It is not uncommon for a group of questions to have the same condition. Luckily you can copy this condition to any subsequent question from the conditions designer once a first condition has been set.
The conditions applying to the current questions are displayed with a checkbox on their left. You can:
Then select all subsequent questions in the survey on which you want to copy the selected conditions from the bottom Select box by highlighting them (using the CTRL key to select multiples). Then click on the "Copy Conditions" button to copy them across.
It is usually best to leave this until you have finished entering all your survey questions, and are satisfied with the question order.
There are a few basic rules you should keep in mind before setting conditions on a question:
Setting the following condition "Show question Q20 if answer to question Q1 is 'no answer'" really means "show question Q20 if question Q1 was displayed and received no answer". This is not equivalent to "show question Q20 if question Q1 was not displayed"
If you set conditions on a question that, itself, has conditions, then there may arise occasions where the survey behaves in ways you might not have predicted. For example a typical side-effect is that if you hide all questions in a group with chained conditions that the group header will still be shown unless you correct these conditions as explained below.
In the example above a question is displayed 'Do you like being male?' which has conditions set, and which will only display if the answer to What is your gender? is M. If you were to add a condition to this question requiring a specific answer from the Do you like being male? question, then this question will never display, because the question Do you like being male will not be presented.
It is highly recommended that you copy the conditions from the earlier question to the one you're editting.
For instance, you want the following:
What you really need to setup is the following set of conditions:
After correction, the correct set of conditions for Q3 should look like:
So if you are designing a complicated survey with large number of conditions, make sure you test the survey for as many different combinations of results as you can think of.
If you create a survey where many questions get skipped because of conditions, the progress bar will jump a big step forward, or the survey ends at 50%.
To avoid such behavior, the questions that could be skipped, should be arranged between the shown questions, so that only one or two questions get skipped per answer.
For Example: based on question one (yes or no question) 14 questions will be asked question 2A to 15A when the answer of question one was yes, 2B to 15B when the answer to question one was no.
If you arrange the questions in one group and arrange them like: 2A, 2B, 3A, 3B, and so on you will get a nearly correct progress bar, while arranging the questions like 2A, 3A, 4A, [...], 2B, 3B, 4B, ... you will get a progress bar from 0 to 50% or from 50% to 100%, depending on the answer to the first question.
You have to use the internal representation of Date values, which is YYYY-MM-DD to define your constant comparison value.
In the multiple options question type, you can use the "Other" provided in the question type as a valid choice but you cannot set conditions on it. For example: Question No 1 says "Which color do your prefer to use?" Answer checkbox choices are Blue, Black and Other. If the participant chooses Blue, you can set a condition. If the participant chooses Black, you can set a different condition. However, if the participant chooses "Other" and types in something in the text box, there is NO way a condition can be set. LimeSurvey does not recognize if the participant chose the "Other" condition. This is NOT a bug but a limitation.
There is no real field recorded for the 'other' checkbox for this question type. Thus, the only way to know if the user has answered the 'other' part of the question or not would be to check if the value of the text written in the other input field is empty or not.
However, due to the specific way we handle Multiple choice questions, testing the 'other' text input field has never been implemented.
As a workaround, add an explicit answer option called 'Other' and do not use the built-in 'other' option of these question types. Then add an additional short text question which will be displayed if this 'Other' checkbox was clicked.
If you want to design something like:
(condition1 OR condition2) AND (condition3 OR condition4)
you'll have to set up:
(condition1 AND condition3) OR
(condition1 AND condition4) OR
(condition2 AND condition3) OR(condition2 AND condition4)