Best Practices for Conditional Logic Rules
Available on the Advanced and Enterprise tiers:
Contents
About
While Conditional Logic in forms simplifies mobile users' workflow, as you build more complex Conditional Logic into forms there are more opportunities to make mistakes in building it. This article is a best practices guide and will discuss a number of potential pitfalls when building Conditional Logic forms.
Note: To make sure your Conditional Logic rules work as intended in the field, test them thoroughly before you deploy the form. Test the form under a variety of conditions to validate the field user experience.
Evaluating a Single Logic Rule
The Form Builder
The Form Builder is the tool that form designers use to create forms. In the Form Builder, accessed from the TrueContext Web Portal, form designers can add and edit pages, sections, and questions, as well as attach data destinations and configure the form's settings. prevents most errors that are contained within a single Conditional Logic rule. In most simple cases, the Form Builder will only let you deploy the form if the rule is valid.
Errors that will prevent you from saving a form:
In your IF Statement...
- You have an incompatible reference question/operator combination
- You are comparing a reference question to an incompatible constant or question
- A question referenced is not in a valid part of the form for comparison (it is inside of a repeatable section A Repeatable Section is a subform that contains a set of related questions. The data captured is “repeating”, because the field user can complete the same subform more than once, which creates multiple entries., and the Conditional Logic is written at the form level)
In your THEN Statement...
- You are performing an action that is invalid for the action target (the page, section, or question that you are acting on)
- You are setting a question to an invalid constant or data type
- The action target does NOT appear in the form after all the elements in your "If"
- The action target is in an area of the form that is not valid to be acted on (it is inside of a repeatable section, and the Conditional Logic is written at the form-level, rather than within the repeatable section
Errors that you must check for:
- Elements of your IF statement contradict each other
- I.e., You have not set up the rule so that it can never be true
- Example:
- IF Q1 = 5 AND Q1 = 8
- Elements of your THEN statement contradict each other
- I.e., You have set up the rule so that it is impossible for the action occur
- Example:
- THEN Q1 is visible AND Q1 is not visible
Evaluating Your Conditional Logic as a Whole
The Form Builder validates that each individual rule is valid, but it does not validate Conditional Logic rules against one another. As you build more complex Conditional Logic into a form, there are a number of things to watch out for.
When you have many Conditional Logic rules, the easiest way to get an overview of them is in the Web Portal. See here for more information. Another way to view the Conditional Logic rules is in the Excel Form Report.
Conflicting Conditional Logic Rules
Watch out for Conditional Logic rules that overwrite the action of another rule.
THEN Q3 is Visible
ELSE Q3 is Not Visible
THEN Q3 is Not Visible
ELSE Q3 is Visible
In the example above, while each rule is perfectly valid on its own, Q3 will have strange behaviour. If Q1 does equal 5, and Q2 is indeed less than 3, the visibility of Q3 will depend on which question the mobile user last interacted with -- so if they last modified Q1 that is the rule that will control the behaviour.
It would be best to rewrite this as a single rule:
IF Q1 = 5 AND Q2 ≥ 3
THEN Q3 is Visible
ELSE Q3 is Not Visible
Tip:Else statements are optional.
Troubleshooting Inconsistent Form Behaviour
When building Conditional Logic, remember that Conditional Logic is not the only thing acting on a form—your field users are as well! Remember that the behaviour of mobile users will always have more of an impact on the outcome of a form than Conditional Logic does.
Users overwriting your Conditional Logic outcomes
Imagine you have a form with the rule below.
THEN Q3 is set to "Fail"
ELSE Q3 is set to "Pass"
After using the form successfully in the field for a while with no issues, you receive a form submission where Q1 had the answer of 30 (a very failed inspection), yet Q3 is marked as "Pass."
What happened?
- First, check your Conditional Logic
- If there are no rules that would have overwritten this, it's highly likely that the mobile user manually changed the answer of Q3.
If you are conditionally setting the values of a question, it's best to make sure that question is also Read-Only (conditionally or not), unless you are okay with users making manual changes to it.
ELSE: What happens when users change their minds?
As Conditional Logic affects the workflow a user sees, it is important to think about what happens when a user goes back and changes an answer. This section will discuss best practices to avoid confusion or showing unnecessary information based on answers being changed.
ELSE Actions must include undoing all IF Actions
When building Conditional Logic workflows, it is important to keep in mind what happens when an answer is changed, and build appropriate actions into all ELSE conditions. Using our room inspection example:
- If the room gets a score of less than 50, the inspection has failed. Users will then see a Required Comments section, and see Page 2, which contains questions for failed inspections.
- If the room gets a score of above 50, the inspection passes and the Required Comments section is not shown/available, nor is Page 2.
| Conditional Statement | Result | |
| "Good" ELSE | If Q1 <50
|
This "ELSE" defines what to do if Q1 is not <50. This causes the following sequence:
|
| "Bad" ELSE | If Q1 <50
|
This "ELSE" condition only works on the first encounter with the question. The sequence would be:
|
The Form Builder auto-generates ELSE statements, but you don’t have to use these. Else statements are optional
Ignored vs. Not Visible: What's the Difference?
Pages and Sections can be ignored, while Questions can be made visible/not visible. Read more about the available actions in Conditional Logic here. Understanding this concept is important if you are building complex forms.
Remember that:
- Data in "Ignored" parts of the form does not exist as far as the form is concerned
- It will not be visible to mobile users
- It will not push information to subsequent fields in the form
- It will not be used in calculations, filters, etc. in subsequent fields in the form
- It will be considered empty if referenced in Conditional Logic rules
- It will not be submitted to the web portal so that it can be reviewed in results
- Therefore, "Ignoring" a page can cause major downstream impacts in a form.
- Data in "Not Visible" question does exist as far as the form is concerned
- Mobile users will not see it, but...
- It can still push information to other questions
- It will be used in calculations, filters, etc. in subsequent fields of the form
- Its value will be used if it is referenced in Conditional Logic rules
- It will be submitted to the web portal
- Therefore, the action of making a question "Not Visible" doesn't affect the downstream flow of the form as much, but the data in it does still affect the form.
What if I want to "Ignore" a question?
If you want a question to be conditionally not visible to users, and you don't want to keep the data in it when it is hidden, here are your options.
- Place the question in a section that you will "Ignore" instead
- Or the Conditional Logic rule that sets the question to "Not Visible" should also "Reset" the Question at the same time.
What if I want a Page or Section to be Not Visible, but I want to use the data in it?
This isn't really possible. We recommend making a series of questions "Not Visible" instead.
Dispatching into Forms with Conditional Logic
When you dispatch a form with Conditional Logic, the Conditional Logic will execute when the user opens the form, to get it into an appropriate starting state (as specified by your Conditional Logic rules). Then, the dispatched fields will get filled. Depending on your Conditional Logic, your dispatched data might conflict with the Conditional Logic rules.
Dispatched Data on Ignored Pages and Sections
In the normal flow of using a form, if a user activity "Ignores" a page or section that already has information in it, that data will "exist" again once the page or section is "Not Ignored".
However, if a page or section is set to "Ignored" as the form is first opening, any information dispatched into those pages will be cleared; so, if a user action sets that section or page to "Not Ignored", that information will not exist.
If you need to dispatch information into Pages/Sections that can be "Ignored" in the form, ensure that they are "Not Ignored" in the starting state of the form, and that only a mobile user action will trigger them to be "Ignored."
Dispatched Data Being Overwritten by Conditional Logic Rules
Again, when a user opens up a form that has been dispatched to them, Conditional Logic runs to determine the starting state of a form, and then the dispatch data is filled.
If the "dispatcher" dispatched a value of "Pass" into a field in the form, but mobile users are reporting they did not receive that value, it is likely that a Conditional Logic rule is clearing/resetting/changing the value of that question as the form opens on the device.
*NOTE: If you are using Conditional Logic to "Set" an answer on a question, we highly recommend NOT dispatching to this question. The Conditional Logic and dispatched data may conflict and produce inconsistent results.