Guide to relevance: properties and important considerations (part 2)

This article is the second part of this feature guide on relevance expressions. To see the first part on getting started, click here.

Additional properties

In part 2 of this guide to relevance, we'll help you solidify your understanding of relevance to help you write the smartest, most efficient relevance expressions possible. There are also a few pitfalls to be aware of, so read on.

Difference from paper logic

The way relevance works might be a departure from how you are used to thinking about skipping questions in a questionnaire. In a paper questionnaire, you might have seen instructions like, "if the answer to question C is no, skip to question F". Firstly, there’s no need to include instructions like this in a digital form, because your relevance conditions will achieve this. Secondly, relevance is defined from the perspective of each field that might be skipped - not in relation to the field which is the condition for skipping a field. So in this example, question C doesn’t have any relevance conditions but questions D and E will need a relevance condition in order to be skipped so that the next question is F under these conditions.

Groups and relevance

To apply the same relevance to more than one field so that they are skipped under the same conditions, you can create a group and place fields within that group while applying the relevance to the group as a whole. Relevance applied to a group applies to all fields inside the group. It is often worth creating a group just to avoid repeatedly applying the same relevance to multiple fields. A common use case for group relevance is informed consent, whereby a large group of fields can be skipped when a respondent does not agree to respond to a questionnaire.

Evaluation between screens

Relevance is calculated between screens in SurveyCTO, so this means that fields inside the same group with the "field-list" appearance option relevance conditions based on fields inside the same group.

If you do make a field relevant based on another field inside the same field-list group, it will become relevant only after you have passed it, as though you had skipped the field. This can be problematic because if such a field were required (which is advisable), if you got to the end of a form and tried to finalize the form, it would identify that there was an unanswered field, and the user will be returned to the top-most unanswered field. By this time, it may not be possible to easily answer the question.

Inherited relevance

Because relevance is calculated between screens in SurveyCTO, this can help simplify relevance in longer chains of skip-logic. For example, "field_C" is relevant based on "field_B", and "field_B" is relevant based on "field_A". Because they are relevant on one another, they cannot be inside the same "field-list" group, as above. What should the relevance for field_C be? Should "field_C" have a relevance condition based on "field A"? No, it would be redundant to do that.

To illustrate this point, compare these two scenarios:

In the redundant relevance scenario for "field_C", the relevance condition based on "field_A" is redundant because it is logically inherited from "field_B". It is not possible for "field_C" to be relevant at all if "field_A" has a value other than 1 anyway, given that the relevance for "field_B" requires that "field_A" is equal to 1. Both of these relevance conditions for "field_C" will work the same but it is better to have the simplest, shortest relevance conditions whenever possible.

Removing or skipping fields through form design updates

If you decide to remove a field from a form design in an update to the design, you can just delete the field. Deleting a field may have the consequence that historical data for the deleted field will not appear in exports. Alternatively, you could also revise a field's relevance expression to "0" (without the quotes). The value, 0, also means "false" in SurveyCTO expressions. If relevance for a field is always false, that means that field will never appear for the user of the form. Doing this will mean that historical data will continue to appear in exports.

To see working example relevance expressions, click here to see the third part of this guide.

Do you have thoughts on this support article? We'd love to hear them! Feel free to fill out this feedback form.