QSM Logic - WordPress Plugin

How to Configure QSM Logic for Smart Surveys and Branching Quizzes

QSM Logic is not just there to add one more tab to Quiz and Survey Master. Its real purpose is different: it makes a quiz, test, form, or survey respond to the user's answers. In this guide, we will walk through how to prepare the foundation in QSM, enable logic, build clear rules, test the result on the live front end, and avoid common pitfalls such as a missing submit button, pagination conflicts, and overly complicated branches.

This guide is written for site owners, instructional designers, marketers, course editors, and webmasters who already understand what the product does and want to move from a "conditional logic plugin" product page to a working real-world setup. We will not cover purchasing, payment, or activation workarounds. The focus here is practical configuration of an add-on you already have, testing conditions, troubleshooting, and deciding whether QSM Logic is actually a good fit for your question structure.

One principle matters above all: branching is only useful when it makes the experience shorter and more precise. If every condition is added "just in case," the quiz becomes fragile: users do not see the right question, administrators lose control of the flow, and the final page no longer matches the answers given. That is why we will move from the question map to the settings, then to test runs, and only after that to publication.

What Conditional Logic Solves in Quiz and Survey Master

A standard quiz follows a fixed linear path: one question, then the next, then the result. That structure works for a simple knowledge test, but it quickly becomes limiting when users arrive with different goals. In a customer survey, not everyone needs to see the section about negative experiences. In a learning assessment, beginners do not always benefit from advanced questions. In a service intake form, someone who selects a personal project does not need questions meant for a corporate procurement team.

QSM Logic adds a rules layer on top of a quiz or survey you have already created. A rule can be described with a simple formula: if a specific answer is selected or a condition is met, show, hide, end, or move the user forward along a defined path. The developer documentation confirms the basic condition operators: is equal to, is not equal to, is greater than, is less than, is empty, is not empty. This matters especially for numeric and text-based answers, because the logic does not have to rely only on "yes" or "no" choices.

The add-on includes several action types. The easiest to understand are Show and Hide, where a question or category appears only when the answer matches. The documentation also describes Go to Pages for jumping to a specific later page in the quiz and End Quiz for stopping the quiz immediately when a certain answer is chosen. There is also a separate practical layer for emails and result pages: a user can receive a different result or email depending on their answer, score, percentage of correct answers, or category, if those conditions are supported by your QSM setup and add-ons.

When logic genuinely improves a quiz

The best use case for QSM Logic is when you have questions that should not appear for everyone. For example, in a satisfaction survey, you might ask for an overall rating first. If someone gives a low rating, you can show follow-up questions about the reason: delivery, support, product quality, or price. If the rating is high, you can instead ask whether they would be willing to leave a review. The user does not waste time on irrelevant fields, and the site owner gets cleaner data.

In a training quiz, logic can separate users by skill level. If someone answers the basic section correctly, you can show a more advanced question or send them to the next page. If the answer is wrong, you can end the attempt, show a hint, or keep an extra reinforcement question in the flow. The key is to decide in advance what counts as the outcome: collecting data, checking knowledge, segmenting the user, recommending something, or giving personalized feedback.

When the add-on may be unnecessary

If a quiz has only five questions and every participant must answer all of them, QSM Logic may add maintenance overhead without delivering much value. In some cases, standard score-based results, question categories, or separate result pages in QSM are enough. Logic is useful when you need different paths, not just different text at the end.

You should also be careful with long branching trees where every answer leads to a new question and every new question opens three more branches. Those setups may look elegant on paper, but they are hard to verify in the admin panel. For anything complex, it is better to build a route map in a table or diagram first, and only then turn those rules into QSM logic.

What to Check Before Installation and Configuration

Before installing the add-on, do not just verify that the main QSM plugin is present. Conditional logic depends on the quiz structure, question types, pagination, and how the user is expected to reach the submit button. If those pieces are not thought through in advance, the issue may look like an add-on bug when the real problem is a contradictory flow.

The foundation: QSM, questions, and page order

QSM Logic works as an add-on for Quiz and Survey Master, so you need a functioning quiz or survey in QSM first. Make sure the questions already exist, the answers are saved, the pages are split in a sensible way, and the quiz can be completed without logic. This is the basic checkpoint: if the linear version does not run to the end, branching will only make troubleshooting harder.

In WordPress, that usually means the following order:

1. The main Quiz and Survey Master plugin is installed and activated.
2. A quiz or survey has been created in QSM or Quizzes/Surveys.
3. The questions have clear titles, because those are what you will later select in the rules.
4. The quiz has been published or at least saved in a preview-ready state.
5. You have tested the standard flow without logic enabled.

Do not start with rules. Start with content and flow. One practical habit is to temporarily add short technical labels to questions, such as Q1: level, Q2: goal, Q3: issue. If the QSM interface shows several long questions that look almost the same, the chance of picking the wrong condition goes up significantly.

Pagination and the Auto Pagination limitation

The QSM Logic documentation specifically warns that logic rules are disabled for Auto Pagination when the Questions Per Page setting is enabled in QSM. In that case, the rules may be ignored. This is an important limitation because many site owners turn on automatic pagination to make a long test easier to navigate, then wonder why branching does not change the question order.

Check pagination before configuring logic. If the quiz needs to branch across pages or hide questions, do not rely on automatic question distribution. Build the pages manually and test the route.

If you need a paged structure, decide in advance which questions belong on each page. This matters especially for the Go to Pages action, because the destination page must come after the current one. The documentation states that going backward is not supported: the logic is designed for forward movement along a sequential path.

Question types and conditions

Not every condition type is equally useful for every question. For choice-based questions, equality or inequality checks make sense. For numeric fields, you can use "greater than" and "less than." For text fields, it is usually safer to test whether the field is filled in rather than trying to build a complex semantic check. If users can enter free text, the same intent may be phrased ten different ways.

Before moving rules into QSM, put together a small table:

This kind of draft only looks unnecessary when you are building your first tiny quiz. In practice, it saves time because the admin panel becomes a place to transfer an already clear plan, not a place for trial and error.

Installing the Add-On and Running the First Check in WordPress

QSM Logic installs like a standard WordPress plugin, but once activated it becomes part of the QSM workflow. The official documentation describes the manual method through a ZIP upload on the Plugins - Add New - Upload Plugin screen, as well as the separate QSM installer used to manage add-ons. This article does not cover purchasing or entering a key, but it is important to understand where to find the feature after installation.

After activation, the quiz list includes access to logic settings. The documentation states that a Logic item appears for the quiz or survey, and that a Logic tab is available inside the quiz editor. If you do not see it, first check that both the main QSM plugin and the add-on are active, then make sure you are editing an existing saved quiz rather than an empty draft.

Initial post-activation check

Do not jump straight into a complex branch. Start with a short one-rule test:

1. Open a test quiz you have already created.
2. Add one question with Yes and No answers or similar options.
3. Add a second question that should only appear for one of those answers.
4. In Logic, create a rule: if the required answer is selected, show the second question.
5. Save the changes and go through the quiz as a regular user in a separate browser tab.

This minimal test confirms that the add-on is connected, the tab works, the rule saves correctly, and the front end reacts to the answer. If the issue appears even here, there is no point in building dozens of rules. First resolve the basic cause: a pagination mode conflict, an inactive add-on, an unsaved quiz, page caching, or the wrong source question.

Testing on a dedicated page

QSM can display a quiz using a shortcode, widget, or block. For troubleshooting, it is easier to use a separate draft WordPress page with no complicated page builder layout, popups, or aggressive optimization. Insert the quiz the same way you normally do on the site, but test it in a calm environment first.

If the production page uses caching, minification, deferred script loading, or a heavy builder, a temporary test page helps separate a logic problem from an environment problem. If everything works on the test page but not on the live one, the cause is almost certainly not the rule itself but the rendering environment.

Understanding the Logic Tab: What a Rule Is Made Of

The QSM Logic interface is built around two conceptual parts. The first defines the condition: When This Happens. The second defines the action: Do This or Then. This phrasing is convenient because the rule reads almost like a normal sentence: "when the user selects this answer, show this question" or "when the value is greater than a given number, go to the correct page."

The When This Happens block

This is where you select the source question, the operator, and the value to compare against the user's answer. A common beginner mistake is choosing the wrong question because several of them look similar in the list. That is why it helps to clean up question names in advance for complex quizzes. If a question is called "Tell us more" and there are three of them, the administrator will quickly lose track of which rule belongs to which actual path.

Equality operators work well for answer choices. Greater-than and less-than operators are meant for cases where the answer is a number or a score. Empty and not-empty checks can be used with open text fields, but they work best as a coarse filter: the field is filled in or it is not. If you need precise text analysis, QSM Logic alone should not be turned into a meaning-detection system.

AND and OR conditions

The documentation mentions additional conditions, and the changelog shows that OR conditions were added in a later release branch. In practice, that means a rule can be not only standalone but also composite. For example, you can show the question "What specific issue came up?" if the user gave a low rating and selected the "delivery" channel. Or you can send users to the same next section if they picked one of several similar options.

Composite conditions require discipline. Do not pack five different meanings into one rule. If you cannot explain the rule in one short sentence, split it into several clearer rules or revisit the quiz structure. The complexity should live in the user scenario, not in the administrator's attempt to keep every condition overlap in their head.

The Then block: show, hide, go to pages, end quiz

The second part of the rule defines the response. Show reveals a question or category when the condition is met. Hide removes an irrelevant block. Go to Pages sends the user to a later page in the quiz. End Quiz finishes the attempt if a selected answer should lead directly to result submission.

For most surveys, start with Show and Hide. They are easier to test and do not disrupt the page sequence itself. Go to Pages is useful when the quiz is already split into clear pages and you need to skip a large section. Use End Quiz carefully: the documentation notes that the end action must be the only action in the Then block and should not be combined with Show or Hide.

Why it is better to start with question visibility

Showing and hiding are easier to test. The user stays in a familiar flow, and the administrator can see exactly which question appeared or disappeared. Page jumps require more control: you need to verify the page name, its order, the presence of a final page, the submit button, and the absence of backward jumps. If you are just getting started with QSM Logic, build one branch using show and hide first, then move on to page routing.

Detailed Setup After Installation: Flow, Rules, and Rollback

The main QSM Logic configuration does not happen in global settings but inside a specific quiz. That means the right working order looks like this: first question structure, then a draft route map, then rules, then tests. If you do it the other way around, you will keep coming back to the questions, changing answers, and breaking conditions you already created.

Build a route map before creating rules

For a small survey, a simple table is enough. For a long test, a diagram is better. Each node should have a question, a possible answer, and a next action. For example:

• If the user says they are a beginner, show the basic question block.
• If the user says they have already taken the course, show a question about previous experience.
• If the user selects "I only need pricing," send them to the page with commercial terms.
• If the user selects "I do not want to continue," end the quiz and show a neutral result.

QSM Logic makes it easy to create a rule, but hard to see the full route at a glance. That is why the map is not just a nice-to-have. It is your way to control dead ends. Every path should have a clear finish: a question, a result page, an email, a form submission, or an end state.

Configure rules from simple to complex

Do not add every rule in one pass. Start with the main question that splits the audience into the largest groups. Then test that branch on the live front end. After that, add the next clarifying question. This way, if something breaks, you will know exactly which rule caused it.

A practical order looks like this:

1. Create the rule for the first branch and save the quiz.
2. Go through the quiz as a user with the answer that should open that branch.
3. Go through the same quiz with the opposite answer.
4. Verify that hidden questions do not require answers and do not block submission.
5. Only then add the next rule.

This approach is slower at the beginning but faster overall. If you create ten rules and then see the wrong result, you have to inspect all ten. If you add them one at a time, the error appears immediately after the specific change that caused it.

Settings you should leave alone until testing is done

While you are building logic, do not enable every extra optimization at the same time: aggressive caching, combined scripts, advanced theme settings, redirects, or popup forms layered over the quiz. First confirm that QSM Logic works in a standard configuration. Then bring the surrounding environment back one element at a time and verify the result.

This matters especially on sites where the quiz is embedded in a builder page or displayed inside tabs, accordions, and popups. Hidden containers can affect how scripts behave. If the quiz needs to live in a more complex interface, test it on a regular page first and only then move it into the target layout.

How to roll back a questionable rule

Rollback in QSM Logic should be simple. Before changing a complex rule, save its wording in a draft note: which question, which condition, which action. If the flow becomes incorrect after the edit, do not try to fix everything at once. Disable or delete the last rule, save the quiz, and run the test again. If the problem disappears, you have found the cause.

A rule is only ready after two checks: when the condition is met and when the condition is not met. Testing only the "positive" path does not prove that everyone else will see the correct route.

Scenarios Where QSM Logic Works Best

QSM Logic is especially useful when the same quiz needs to behave differently for different people. The examples below are not abstract "features" but working scenarios that solve real site problems.

Satisfaction survey with follow-up questions

Imagine a service-based website. The first question is: "How would you rate the quality of support?" If the user selects a low rating, a follow-up block appears: response speed, completeness of the solution, politeness, and clarity of the instructions. If the rating is high, you can hide the negative block and instead show a prompt to leave a review or a question about what they liked most.

The benefit here is twofold. The user does not see unnecessary questions, and the site owner receives segmented answers. Instead of a vague complaint like "support is bad," you can identify the specific stage causing the issue. For this kind of setup, use Show for follow-up questions and make sure hidden required questions do not block submission.

Level placement in a learning test

In an educational project, you can start with a diagnostic question or short introductory block. If the user answers confidently, they are shown the next-level questions. If they get it wrong, you can show basic questions, hints, or end the quiz with a recommendation to review the material.

The important thing here is not to turn logic into a punishment. The user should understand why the path changed. In the question text or final result, explain that the next section was selected based on their answers. If you use End Quiz, the final message should still be useful: what to review, where to go next, or which material to open.

Lead form with different branches by customer type

For a consulting website, the first question can split the audience into individual clients, companies, and partners. Individual clients might see questions about goals and timing. Companies might see questions about budget, team size, and integration requirements. Partners might see questions about the type of collaboration. In a standard form, all of those fields would sit on one page and likely discourage the user.

In QSM Logic, this scenario works best by showing and hiding blocks of questions. If the quiz spans multiple pages, you can use forward jumps, but the path should remain simple. Do not try to send users back to earlier pages: that is not supported for Go to Pages and is difficult to follow in any case.

Personalized emails and results

The QSM documentation describes conditions for emails and result pages. QSM Logic specifically notes additional support for answer-based conditions in email templates and result pages when the add-on and the QSM core are on compatible versions. That means branching does not have to end with question visibility. The user can receive a different email or see a different result page.

For example, in a course recommendation survey, the user selects a goal such as "career," "exam," or "general improvement." After completion, everyone sees a result, but the email contains different recommendations. The important point is not to promise automatic marketing segmentation beyond what QSM can actually do. Configure only the conditions that are available in your version of the interface and confirmed by the documentation.

Practical Example: A Branching Survey for Consultation Requests

Let us walk through a specific scenario you can reproduce on a test site. The goal is to create a short survey where the user first chooses the type of request and then sees only relevant follow-up questions. This is not a purchase example and not a payment form. It is a routing flow that helps collect an inquiry without unnecessary questions.

Goal

You need three branches:

• If the user selects "Launching a new project," show questions about timing and target audience.
• If the user selects "Improving an existing website," show questions about the current issue and platform.
• If the user selects "Team training," show questions about participant count and current skill level.

At the end, the user should submit the survey and receive a clear result or email if the corresponding conditions are configured in QSM.

Preparation

Create a test survey in QSM with the main question "What do you need help with?" Add three answer choices. Then create two follow-up questions for each branch. At this stage, do not configure logic yet. First make sure all questions save correctly and the survey can be completed in linear mode.

Next, organize the questions by meaning. The branches should be independent. The question "How many participants will be in the training?" should not be required for a user who selected website improvement. If you leave it required and only hide it visually, verify that QSM does not still require an answer to that hidden question at submission time.

Configuration steps

1. Open the survey editor and go to the Logic tab.
2. Click Create New Rule or the equivalent rule creation button.
3. In the When This Happens block, select the question "What do you need help with?"
4. For the first rule, set the condition so the answer equals "Launching a new project."
5. In the action block, select Show for the questions about timing and audience.
6. Repeat the rules for the other two branches.
7. If extra questions are visible before the answer is selected, add hiding rules for irrelevant blocks or check the default question state in your interface.
8. Save the rules and go through the survey three times, once for each branch.

After each run, write down which questions appeared. Do not rely on memory. If the "Team training" branch shows a question from the "Website improvement" branch, the rule is pointing to the wrong target or an old rule was never removed after editing.

Expected result

The user sees the main question, picks an option, and then gets only their own branch. There is a submit button at the end. The result page or email does not contain empty blocks tied to hidden questions. The administrator receives answers that are easy to review: the main request plus branch-specific follow-up details.

A detail that often gets in the way

If you use a paged survey and the logic jumps across pages, make sure there is a final page or final text that does not disappear because of conditions. The official QSM Logic documentation specifically discusses the case where a quiz loses its submit button and suggests two safe approaches: add text after the quiz or create a last page that is not included in the logic. This is not cosmetic. It is a way to let QSM consistently carry the user to the final action.

How to Verify the Result on the Site Before Publishing

Testing QSM Logic should be scenario-based. It is not enough to open the page and confirm that the first question appears. You need to go through every branch, verify submission, results, emails, hidden required fields, and behavior inside the real site environment.

Minimum test matrix

Create a table where the rows are user paths and the columns are checkpoints. For example: selected answer, which questions appeared, which were hidden, whether the Next button appeared, whether the Submit button appeared, which result page was shown, whether an email was sent, and whether the answers were saved in the admin panel.

For every rule, verify two states:

• The condition is met - the target question, page, or action should trigger.
• The condition is not met - the user should not end up in someone else's branch.

Be especially careful with answer choices that are close in meaning. For example, "personal project" and "small business" might lead to different branches, but the user responses feel similar. If the administrator accidentally chose the wrong answer in the rule, the issue will only show up during a full walkthrough.

Testing with caching and optimization

After a successful test on a simple page, move the quiz back into the real site environment. If the site uses caching plugins, deferred script loading, or minification, clear the cache and test again. There is no need to permanently disable all optimization at once. First compare: does the quiz work on the test page without optimization, and does it break on the target page? That gives you a clear starting point for exclusions.

If the issue appears only for guests, test the page in incognito mode or in another browser. A WordPress administrator often sees an uncached version, while regular visitors see a cached one. For logic-driven quizzes, that matters because the scripts have to react to answer selections in real time.

Checking the data after submission

After the test runs, open the results in the QSM admin panel. Make sure answers are being recorded, hidden questions are not creating strange empty required values, and the final pages match the selected branch. If emails are involved, send test messages to a controlled address and verify not only that they are sent, but also that the content is correct.

Conditional logic can make a quiz more personal, but it does not replace editorial review. If a user went through the "new project" branch, the email and result page should not speak to them as if they were in the "team training" group. It seems minor, but those mismatches are exactly what reduce trust in a form.

Limitations, Compatibility, and Safe Improvements

QSM Logic works inside the QSM ecosystem, which means it inherits both its strengths and its limitations. It should not be evaluated as a standalone builder for every possible workflow. It is an add-on for quizzes, surveys, and forms already created in QSM.

What the documentation and changelog confirm

The key confirmed facts are these: the add-on provides conditional logic for showing and hiding questions, supports a set of comparison operators, works with additional conditions, includes actions for moving to later pages and ending the quiz, and integrates with email and result conditions when the versions in your setup support it. The changelog also shows fixes related to JavaScript conflicts, hidden required questions, multiple rules, quiz duplication, HTML answers, results, and AJAX handler security.

These notes are useful not because you should insert dates into the article, but because they give you a troubleshooting direction. If you are on an older installation and the problem looks similar to something already fixed in the changelog, your first step should be to check updates on a test copy of the site. Do not blindly update a production site right before an important lead capture campaign or exam. Make a backup first and verify the flow.

Where logic can conflict with design and theme behavior

The logic itself changes question visibility and the path through the quiz. A WordPress theme, page builder, or optimizer can affect how those changes appear. Problems usually look like this: a question does not show up, a button does not update, the page does not scroll to the next block, hidden elements leave empty space behind, or the script works only after a page refresh.

A safe troubleshooting sequence looks like this:

1. Test the same quiz on a clean test page without a complex layout.
2. Temporarily disable only JavaScript optimization for the quiz page, if that setting exists in the caching plugin.
3. Check for conflicts with a specific builder element: tab, modal, accordion, or slider.
4. Restore settings one by one and note after which change the logic stops working.

Do not edit WordPress core files, QSM files, or the add-on itself. If you need to change the appearance of questions, use QSM settings, theme styles, or safe CSS in a child theme only after verifying the actual classes on your site. This guide does not include a CSS snippet because the official sources do not provide one stable class set for every theme and output mode, and an invented selector is more likely to cause problems than solve them.

A safe no-code improvement: a fallback final page

The most useful improvement for branching quizzes is not code but an editorial safety net. Add a final page or final text that does not depend on complicated conditions and helps the user understand what to do next. This matches the documentation's recommendation for the missing submit button case: the last stage should not be fully consumed by logic.

On that page, you can place a short instruction such as "Review your answers and submit the form" or "Thank you, one final step remains." What matters is that this page is not a target for accidental backward navigation and is not hidden by rules. That way, even a complex route still ends predictably.

How to Design Branches So the Rules Do Not Turn Into Chaos

The most common mistake with conditional logic is starting from the interface instead of the route. The Logic tab looks simple enough: choose a question, choose a condition, choose an action. Because of that, it is tempting to add rules on the fly. On a small test, that approach is still manageable. On a real survey with multiple pages, it quickly leads to conflicts: one rule shows a question, another hides it, a third sends the user forward, and a fourth ends the attempt before the submit button ever appears.

To keep QSM Logic stable, think of branches as routes rather than a collection of isolated tricks. Every route should have a beginning, entry conditions, intermediate questions, a final check, and a clear outcome. If you cannot describe the route in plain language as "a user with this answer should go here, then here, and finish here," the structure is not ready to be moved into the plugin.

Separate visibility rules from routing rules

There are two different kinds of tasks here. The first is visibility control: show or hide a question because it only applies to part of the audience. The second is route control: move the user to another page or end the quiz. In the interface, they may sit next to each other, but conceptually they operate at different levels.

For a simple survey, start with visibility. For example, the main question selects the customer type, and the following blocks appear based on the answer. That kind of setup is easier to debug: the user stays on the page, and you can see which fields appeared. Add routing actions only when you truly need to skip a large portion of the quiz or end the attempt immediately. If every small branch becomes a page jump, the map becomes fragile.

A practical rule is this: if the problem can be solved by showing or hiding one block, do not use page jumps just for the feeling of a "smart" quiz. Jumps are useful for major sections, not for every follow-up question.

Assign internal names to questions

On the front end, a question may sound polished and natural: "What matters most to you right now?" In the admin panel, that kind of name is not always helpful. If the quiz contains several similar questions, the administrator can easily choose the wrong source or target. That is why complex quizzes benefit from a clear internal naming structure, if your editorial workflow allows it.

For example, inside a draft map you might use:

• Q1_goal - the user's main goal.
• Q2_new_project_timing - timing for the new project branch.
• Q3_existing_site_problem - the issue for the existing site branch.
• Q4_training_group_size - participant count for the training branch.

You do not have to display those names to visitors. The important thing is that whoever configures the rules can quickly match the source, condition, and action. If you come back to the quiz a month later and cannot understand why a rule exists, then it should have been named and documented more clearly.

Test the negative path first

Administrators usually test the route they created the rule for: they choose the desired answer, see the correct question, and feel satisfied. But for conditional logic, the negative path matters just as much. If the user selects a different answer, they should not see someone else's branch, should not land on the wrong result page, and should not receive an email meant for a different scenario.

After creating each rule, ask yourself two questions:

1. What should happen if the condition is met?
2. What should happen if the condition is not met?

If you do not have an answer to the second question, the rule is potentially dangerous. It may leave the question in its default state, show an unnecessary block, or prevent the user from reaching the end. This matters especially in QSM Logic because showing, hiding, jumping, and ending can stack on top of each other.

Do not mix editorial segmentation with technical filtering

Sometimes a site owner tries to use QSM Logic for tasks that are better handled by content or results. For example, if you need to show different recommendations based on the final score, you do not always need to branch the entire quiz. Result page conditions may be enough. If you need to send different emails, you do not necessarily have to hide questions halfway through the flow. First decide where the variation should happen: in the questions, the pages, the email, the result, or the admin-side processing.

That choice reduces the number of rules. If the user genuinely does not need a question, use visibility. If all users should answer the same questions but receive different recommendations, use result conditions. If you need different follow-up emails, configure email conditions. Question logic should control the path through the quiz, not every kind of personalization all at once.

Emails and Result Pages: How to Connect Branching to the Final Message

A branching quiz loses much of its value if the final message remains identical for everyone. The user went through a personalized path, answered follow-up questions, and then sees the same generic "Thanks for participating." Sometimes that is enough, but in most cases the result or email is what turns the survey into a useful tool: it gives a recommendation, explains the next step, provides context to the administrator, or shows the user why they were placed in a particular group.

The QSM documentation for results explains how to create multiple result pages with conditions, and the email documentation describes conditions for email templates. The QSM Logic page also mentions support for answer-based conditions in email templates and result pages when the versions in your setup support it. So after configuring question visibility, you should separately verify the final communication. Do not assume it is automatically correct just because the right questions appear.

Divide results into meaningful groups

For a practical setup, you do not need to create a unique result for every single answer. That leads to dozens of templates that are hard to maintain. It is better to define three to five meaningful groups. For example, in a consultation survey, those might be "New Project," "Current Site Optimization," and "Team Training." In a learning test, they might be "Needs a Basic Review," "Ready to Move Into Practice," and "Prepared for the Advanced Section."

Each group should include:

• A short explanation of why the user is seeing this result.
• One main next step.
• Neutral wording with no promises of guaranteed success.
• A link or instruction, if your editorial scenario calls for it.

If the result depends on scores, use score and percentage conditions where QSM provides them. If the result depends on a selected answer, verify which conditions are available in your version of QSM Logic. Do not replace a confirmed mechanism with assumptions: if the condition you need is not visible in the interface, do not write in your guide or instructions that it "should" work.

The user email should match the visible branch

If the user went through the "team training" branch, they should not receive an email about a site audit. That sounds obvious, but email is exactly where branching mistakes often surface: the administrator tested only the public page and never opened the message that was sent. That is why email belongs in the test matrix.

Check email with this sequence:

1. Go through the route as a user in the first branch.
2. Open the email and verify that the subject, greeting, and recommendation match the answers.
3. Check that the email does not contain empty variables or blocks tied to hidden questions.
4. Repeat the same process for the other branches.
5. Check the default email template in case no condition matched.

The default template matters just as much as the final page. It protects the scenario where the user lands in an unusual combination of answers. A good default should not feel like filler. It can be neutral: "Thank you, we received your responses and will follow up after review."

The administrator email should help with processing

For inquiries and surveys, the administrator email is often more important than the user email. If you use QSM Logic for segmentation, include the key information in the admin email: the selected branch, the main answer, contact details, and responses to follow-up questions. There is no need to overload the message with the entire route if the administrator will later open the full results in QSM. But the email should make it easy to understand what action needs to be taken.

If QSM template variables are used in emails, test them with real submissions. The email template documentation specifically warns about nuances related to category names in variables. That is especially sensitive in branching quizzes: an empty variable in an email looks like a technical error and lowers user trust.

The result page should not expose hidden branches

Sometimes the final text accidentally lists every possible scenario: "If you selected a new project, do this; if training, do that; if audit, do something else." Technically, that works, but it cancels out the value of personalization. The user sees that their route was not really taken into account. If you are already using QSM Logic, make the result precise.

A strong result structure includes:

• One short conclusion for the selected branch.
• An explanation of which answers shaped that conclusion.
• One practical next step.
• A calm disclaimer if the result is not a substitute for professional advice.

Do not use QSM Logic for high-risk promises. In medical, financial, legal, and similar contexts, the result should be a preliminary recommendation or routing aid, not a final diagnosis or decision.

Publication Checklist: What to Test Before Opening the Quiz

Once the rules are created and the individual branches work, there is one last step: publication testing. It is different from setup testing. During setup, you check whether a rule fires. Before publication, you check the full user experience from landing on the page to receiving the result and saving the data.

Test roles and environment

A WordPress administrator often sees the site differently from a regular visitor. They may have different permissions, different caching behavior, the admin bar open, and debugging panels enabled. That is why at least one test should be done as a guest. Better yet, use another browser or incognito mode. If the quiz is intended for logged-in users, test with the actual role that will use it, such as a member, editor, or learner.

If the site uses membership controls, restricted access, an LMS, or a user portal, QSM Logic is no longer operating in isolation. Verify that a user with the correct role can view the page, click answers, reach the result, and avoid access errors after submission. Do not blame a problem like that on logic until permissions and page access have been checked.

Check repeat attempts

Many quizzes are not taken just once. A user may refresh the page, go back, start over, or try again later. If QSM has attempt limits, entry limits, or activity scheduling enabled, those settings can affect your tests. Before publishing, decide what should happen on a repeat attempt.

Key questions to verify:

• Can the quiz be taken again through a different branch?
• Are the answers from the previous attempt stored separately?
• Does the browser back button interfere with the page flow?
• Does the user see a clear message if another attempt is not allowed?
• Do emails and results work the same way on repeat attempts as they do on the first attempt?

If repeat attempts matter for training or testing, do not publish the quiz after a single successful pass. Run at least two attempts through different branches and compare the saved results.

Check the mobile view without inventing separate mobile logic

QSM core presents responsiveness as a plugin feature, but the actual page still depends on the theme, styles, and number of questions. The logic itself should not be "mobile" or "desktop" specific, but hidden and newly revealed blocks can change the page height. On a phone screen, a user may not notice that a new question appeared farther down the page or may not realize they need to scroll.

Test long branches on a phone: does the next question appear within view, is it covered by a sticky site header, are the answer options easy to tap, are the answer labels too long? If a question appears below the fold after an answer is selected, add a short note inside the quiz itself: "After you choose an answer, a follow-up question will appear." That is an editorial fix, but it is often more useful than trying to force the behavior with a script.

Keep a rule change log

For an important quiz, keep a simple log: date of the edit, who made it, which rule changed, why, and how it was tested. You do not need a complex system. A document or tracker task is enough. QSM Logic may be maintained not only by a developer but also by an editor, instructional designer, or marketer. Without a log, no one will remember a few months later why a particular route was chosen.

The log also helps during updates. If behavior changes after a QSM or Logic update, you can compare not vague memory but an actual rule map and test routes. That matters even more because the Logic changelog includes fixes related to rules, results, question hiding, duplication, and security.

Why Rules May Not Work and How to Find the Cause

Troubleshooting QSM Logic should move from simple to complex. Most problems are not caused by the "magic" of conditional logic, but by one of five factors: pagination mode, the wrong condition source, a hidden required question, a public page conflict, or an overly complicated rule chain.

Rules are ignored in the quiz

Symptom: the questions move in a linear order even though rules exist in the admin panel. The user sees content they should have skipped or never reaches the correct branch.

What to check: start with the Auto Pagination setting and the Questions Per Page option. The QSM Logic documentation explicitly states that when automatic pagination is enabled, rules for a specific quiz may be ignored. Then check whether the rules were saved, whether QSM Logic itself is active, and whether you are editing a copy of another quiz.

How to fix it: disable automatic splitting for the test, build the pages manually, save the quiz, and go through the smallest possible route. If the rule starts working, you found the cause. If not, create a new two-question test quiz and verify one simple scenario.

The submit button does not appear at the end

Symptom: the user completes the visible questions, but instead of a final submission option, they only see continued flow or have no way to finish the quiz.

Possible cause: the logic hid or skipped the last part in a way that prevented QSM from reaching its final state. The official documentation describes two practical methods: enable text after the quiz or add a final page that is not included in the logic.

How to fix it: add stable final text in Text - General - Text after Quiz or create a final page with a neutral question or text that does not participate in the rules. Then go through every branch and make sure the submit button appears on each route.

The wrong question appears

Symptom: the user selects one answer, but a block from a different branch opens instead.

What to check: inspect the source question, operator, and target question in the rule. This mistake is especially common when questions have similar names or were duplicated. The add-on changelog includes fixes related to duplicated quizzes and multiple rules, so on older installations it is also worth checking updates on a test copy.

How to fix it: temporarily rename the questions so they are easy to tell apart, delete the questionable rule, and recreate it from scratch. After saving, test only one route. If it works, move on to the next branch.

A hidden required question blocks submission

Symptom: the user does not see the question, but submission fails or the result looks incomplete.

Possible cause: the question is hidden by logic but remains required in the quiz structure or still participates in result evaluation. The QSM Logic changelog contains historical fixes related to hidden required questions, so the problem may depend on the version and the exact structure.

How to fix it: review the required status of questions in branches that may be hidden. If a question should not be asked of everyone, do not make it critical to the overall route without separate verification. Go through the quiz as a user who never sees that question and confirm that submission still works.

The problem only appears on the live page

Symptom: the logic works on the test page but fails in the target site layout.

What to check: caching, JavaScript minification, deferred loading, builder tabs, popups, and theme scripts. QSM runs on the public front end through interactive elements, so the page environment genuinely matters.

How to fix it: temporarily display the same shortcode or block on a simple page. If everything works there, set an exclusion for the quiz page in the caching plugin or move the quiz out of a complex container into a regular block. Roll back changes one at a time so you do not lose the working configuration.

When QSM Logic Is the Right Choice

QSM Logic is worth using if your site already runs on Quiz and Survey Master and you want to make the experience more personal: show follow-up questions, hide irrelevant blocks, move users forward through pages, end the quiz after a special answer, or connect answers to emails and results. It is a strong tool for surveys, educational tests, qualification forms, recommendation flows, and lead segmentation.

You do not need it when every user should go through the same short list of questions. It also should not replace a well-designed quiz structure. The best results come when you map the routes first, then add rules one by one, and test the branches as a regular user after every change.

Before publishing, verify three things: that conflicting automatic pagination is disabled, that there is a stable final stage with a submit button, and that caching and page layout are not interfering with the scripts. Once those points are covered, you can move to the download section and download the latest version of QSM Logic, then test it on a site copy or draft page.

Well-configured logic is almost invisible to the user. They simply answer questions and see only what applies to their situation. That is exactly the goal: not to showcase the complexity of the admin panel, but to make the quiz shorter, more accurate, and more useful.