A condition makes a question appear only when it is relevant. Ask "Which brand do you drive?" only of people who said they own a car, or show a follow-up only to people who rated you poorly.

Two things are worth understanding before you start:

• Conditions hide and show — they do not jump. A question with no condition is always shown; a question with a condition is shown only when that condition is true. There is no "go to question 10". To skip a block of questions, put the same condition on each of them.
• A condition can only look backwards. It can reference questions the participant has already answered, never a later one.

Open the Condition designer

1. Open your survey in the editor and click the question you want to hide or show.
2. In the Question settings panel on the right, choose the Advanced tab.
3. Under Condition designer, click + New logic.

A question that has a condition is marked with a small C badge on its card in the editor, so you can see at a glance which questions are conditional.

Build a condition

Each condition row reads Display only if… and has three parts:

1. What to test. Two tabs, and the difference matters — see Question or participant data? below. Question tests an answer the participant has already given (individual sub-questions are listed too, so you can test one row of an array). Participant data tests something you already know about them from your participant list.
2. The comparison. Open Comparison operator and choose one of seven — Less than, Less than or equal to, equals, Not equal to, Greater than or equal to, Greater than, or Regular expression. The same seven are offered whether you are testing a question or participant data, so there is nothing extra to learn when you switch tabs.
3. What to compare against (Reference value):
   • Select answer option(s) — one or more of that question's answer options.
   • Free value (constant) — a number, some text, or a date (written YYYY-MM-DD).
   • Compare to answer of other question — match one question's answer against another's.
   • Participant data — a value from your participant list. Note that participant data appears on both sides: you can test an answer against something you already knew, for example checking whether the email address someone typed matches the one you invited them on.
   • RegExp — a regular expression. Do not wrap the pattern in forward slashes.

Add more rows with + Add condition, then click Apply. Nothing is saved until you click Apply.

Question or participant data?

These are the two kinds of thing you can test, and they behave differently:

• Question — what the participant tells you, during the survey. It exists only once they have answered that question, so you can only test questions that come earlier. The dropdown is labelled Previous questions for exactly that reason.
• Participant data — what you already know about them before they start, taken from your participant list. It is available from the moment they open their personal link, so it can decide even your first question.

The participant-data fields cover more than the person's details — they also include the state of their invitation:

• Who they are: First name, Last name, Email address, Language code.
• Their invitation: Access code, Email status, Invitation sent, Last reminder sent, Total number of reminders sent.
• Their progress: Uses left, Completed.

That last group is more useful than it looks. Language code lets you branch by the language someone was invited in, and the reminder fields let you ask a different question of people who needed chasing.

Participant data has two prerequisites: the survey needs a participant list to draw from, and Anonymized responses must be off. If responses are anonymized there is deliberately no link between a person and their answers, so there is nothing to test against. This is a real trade-off — promising anonymity means giving up participant-data conditions.

Changing or removing a condition

An existing condition appears in the panel as its scenario and its expression. Click the expression to edit it, or the ✕ beside it to remove it.

Read the confirmation before you click Delete. It asks "Are you sure you want to delete all conditions for this question?" — the ✕ removes every condition on that question, not just the row you clicked. On a question with several conditions, that is more than you probably meant.

How multiple conditions combine — the part people get wrong

You do not choose AND or OR. LimeSurvey decides for you, by what you are testing:

• Conditions testing the same question are joined with OR. ("Answered Poor or Very poor.")
• Conditions testing different questions are joined with AND. ("Owns a car and lives in Berlin.")

You can watch this happen: add a second condition on the same question and the joiner between the rows reads OR; point it at a different question and it reads AND.

These two rules already give you bracketed logic for free. Two conditions on question A plus two on question C evaluate as (A1 or A2) and (C1 or C2) — an and of or-groups — without you doing anything.

What the rules cannot give you is the mirror image: an or between two groups that each need an and — (A and B) or (C and D). There is no way to type your own brackets. That is what scenarios are for.

Scenarios: when the automatic rules are not enough

A scenario is a numbered group of conditions. Inside a scenario, the same/different rules above apply. Separate scenarios are joined with OR — the question is shown if any one scenario is satisfied.

The builder opens with a Default scenario box containing 1; conditions you add belong to that scenario. Give a group of conditions a different scenario number and it becomes an alternative route to showing the question. The numbers are only labels — they need not be consecutive.

Example: show a question to "people in Berlin who own a car, or anyone who complained". The Berlin and car conditions go in one scenario (they are ANDed, being different questions); the complaint condition goes in another. The result is (Berlin and car) or (complained) — the OR-of-ANDs shape the automatic rules cannot produce on their own.

Writing the condition as ExpressionScript

Everything the designer builds is ExpressionScript underneath — the form is a friendly way to write it. Next to New logic there is an Enter expression… field with an expand icon that opens the Condition code window, where you can read or write the expression directly.

The condition "first name is John and they rated Customer support as Poor" is stored as:

(( TOKEN:FIRSTNAME == "John" ) and ( Q001_SQ001.NAOK == "A001" ))

Reading that: TOKEN:FIRSTNAME is participant data; Q001_SQ001 is the sub-question SQ001 of question Q001; A001 is an answer option code. .NAOK means "not applicable is OK" — evaluate this even if the question was skipped, which is usually what you want.

Use the expression field when the form cannot express what you need — real brackets, arithmetic, or functions such as is_empty(), sum() or count(). For example, show a question only when someone actually entered a name:

!is_empty(name)

One important trade-off, which LimeSurvey warns you about: conditions written in ExpressionScript mode can't be displayed inside the visual condition builder. A hand-written expression cannot be rendered back into the form, so use the form for anything the form can do, and keep hand-written expressions for the cases that genuinely need them.

Relevance expressions take no curly braces. Braces are only for tailoring — inserting an answer into text, as in Hello {name}. See Use answers from previous questions (piping).

Showing only the options someone picked (array filtering)

A common need: ask "Which of these did you buy?", then ask a follow-up about only the ones they picked. This is array filtering, and it is configured with question attributes in the classic question editor rather than in the Condition designer.

Open the question in the classic question editor and use the Logic section of its settings panel:

• Array filter — enter the code of the earlier question. This question then offers only the sub-questions or options that were selected there.
• Array filter style — Hidden (unselected items disappear) or Disabled (they appear greyed out).
• Array filter exclusion — the inverse: show only what was not selected.

The rule that catches everyone: the sub-question codes must match between the source question and the filtered one. Filters can also be chained — question 3 filters on question 2, which filtered on question 1 — so each step narrows the list further.

Rules and pitfalls

• Reordering questions can silently break conditions. If you move a question so that it now comes before the question its condition references, the reference is broken and you are not warned. Re-check conditions after reordering.
• Chained conditions need care. If question B is conditional on A, and C is conditional on B, then C is only evaluated when B was shown. When that is not what you want, repeat A's condition on C.
• Test in preview. Use the preview (eye icon) and answer the survey both ways — once so the condition is true, once so it is false.
• Watch the progress bar. If large blocks of questions are skipped, the progress bar can jump around. Spreading conditional questions through the survey rather than clustering them helps.

Related articles

• Use answers from previous questions (piping) — putting an earlier answer into later text.
• Equation question type — calculate a value you can then test in a condition.
• Setting conditions and ExpressionScript examples in the LimeSurvey manual — the full reference.