Adding Conditional Rules

In this tutorial you will add conditional rules to the pet insurance questionnaire from Your First Questionnaire. You will create a blocker screen for users who do not have a pet, and learn how to use grouped conditions for more complex branching.

Prerequisites

• Completed the Your First Questionnaire tutorial
• The pet insurance questionnaire is saved as a draft in Strapi

1. Add a BLOCKER question

A blocker is a dead-end screen. When a user lands on it, they cannot continue the flow. You will use it to stop users who answered “No” to having a pet.

1. Open your pet insurance questionnaire in Strapi
2. In the questions dynamic zone, click Add a component
3. Select BLOCKER

Fill in:

Field	Value
questionId	noPetBlocker
groupId	preQuote
screen.question	Sorry, you need a pet to get pet insurance
screen.description	Come back when you have a furry friend!
layout	Standalone

The Standalone layout gives the blocker full control over the screen — no progress bar, no back button. This is the standard layout for blockers and success screens.

Tip

Place the blocker question after the question it relates to (hasPet) in the dynamic zone ordering. While rules control navigation, keeping related questions near each other makes the questionnaire easier to maintain.

2. Add a simple comparison rule

Now you need a rule that sends users to the blocker when they answer “No” to having a pet.

1. Scroll down to the rules dynamic zone
2. Click Add a component
3. Select rule-comparison (a simple if/then condition — see Glossary)

This rule says: “When the user answers the hasPet question, if their answer is false, send them to the blocker screen.”

Fill in:

Field	Value
questionId	hasPet
Operator (if.op)	equals
Value type (if.variable.type)	static (comparing to a fixed value)
Value (if.variable.value)	false
Then go to (outcome.goTo)	noPetBlocker

Here is what each field means:

• questionId — Which question this rule applies to. The rule is evaluated when the user submits their answer to this question.
• Operator (if.op) — The type of check. equals checks for an exact match.
• Value type (if.variable.type) — Whether you are comparing to a fixed value (static) or to another question’s answer (dynamic).
• Value (if.variable.value) — The value to compare against. Enter false as the value.
• Then go to (outcome.goTo) — The questionId to jump to if the condition is true.

3. Preview the branching flow

1. Save your questionnaire
2. Click Preview
3. Walk through the flow:
   • On the intro, click Continue
   • On “Do you have a pet?”, select No
   • You should land on the blocker screen: “Sorry, you need a pet…”
4. Go back and try again:
   • Select Yes on the pet question
   • The flow should continue to “What type of pet?” as normal

The rule only fires when the condition matches. When the user answers “Yes” (true), the condition (equals false) does not match, so the flow continues to the next question in default order.

4. Add a grouped rule

Suppose you want to add more complex logic — for example, skipping the date-of-birth question when the user has a dog (because dog age is handled differently). This requires checking multiple conditions at once.

1. First, add a new question to skip to. Add a RADIO component:

   Field	Value
   questionId	dogSize
   groupId	preQuote
   required	false
   screen.question	What size is your dog?
   props.mapValue	SMALL / Small, MEDIUM / Medium, LARGE / Large

2. In the rules dynamic zone, add a rule-group-comparison component:

   Field	Value
   questionId	petType
   if.condition	AND
   outcome.goTo	dogSize

3. In the if.comparisons list, add two entries:

   Comparison 1:

   Field	Value
   questionId	petType
   op	equals
   variable.type	static
   variable.value	DOG

   Comparison 2:

   Field	Value
   questionId	hasPet
   op	equals
   variable.type	static
   variable.value	true

This grouped rule means: when the user submits their answer to petType, if petType equals DOG AND hasPet equals true, skip to dogSize.

This second comparison demonstrates how grouped conditions work — in real questionnaires, you will often combine checks on multiple previous answers.

5. Understand rule evaluation order

Rules are evaluated in the order they appear in the Strapi dynamic zone. The first rule whose condition matches wins.

For your hasPet question, you have one rule:

1. If hasPet equals false -> go to noPetBlocker
2. (no match) -> continue to next question in default order

For your petType question, you have one grouped rule:

1. If petType equals DOG AND hasPet equals true -> go to dogSize
2. (no match) -> continue to petDateOfBirth

Avoid using else with multiple rules

If you have multiple rules for the same question, do not use else on any rule except the last one. An else clause acts as a catch-all — it fires immediately when the condition is false, preventing subsequent rules from being checked. See Rule Evaluation for the full explanation.

What you learned

• rule-comparison handles simple “if X then go to Y” branching
• rule-group-comparison combines multiple conditions with AND/OR logic
• Rules are attached to a questionId and evaluated when the user submits that question
• Rules are checked in order; the first match wins
• Blockers with Standalone layout create dead-end screens

Next steps

Your questionnaire now has conditional flow. In Setting Up a Quote Page, you will add a pricing screen where users can see plans, compare coverage, and customize their policy.

See also

• Rule Operators Reference – complete list of all comparison operators, variable types, and rule structures
• Configure Rules – task-focused guide for all rule types (simple, grouped, date, always)
• Rule Evaluation – how the rule engine decides which question comes next, including the “else” pitfall