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 #

Evaluation between screens #

Relevance is evaluated whenever you move from one screen to the next. Starting with SurveyCTO Collect for Android 2.81.7, SurveyCTO Collect for iOS 2.81.2, and web forms on SurveyCTO server 2.84.0, it is also evaluated as you answer questions on a single screen: inside a group with the “field-list” appearance, a field can become relevant (or stop being relevant) immediately based on a response entered earlier on the same screen, without leaving and returning to it. Calculations and labels that reference other fields on the same screen refresh in the same way.

Constraints can also reference values entered in other fields within the same field-list group. They are still checked when you move forward from the screen, not while you are typing, so a constraint message appears when you try to advance.

On older versions of Collect, the older relevance behavior still applies: A field that is made relevant based on the response to another field inside the same field-list group only becomes relevant after you have advanced to the next screen, as though that question has been skipped. If such a field is required, the form cannot be finalized until the user goes back to answer it.

If some of your enumerators use older app versions, please note this limitation and keep fields that depend on answers to previous questions on separate screens from those screening questions.

Inherited relevance #

On older versions of Collect, where relevance must be calculated between screens, you 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.