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 can be calculated between questions that appear subsequently on different screens, or evaluated dynamically within a group that uses the field-list appearance.

Calculating relevance within a field-list group means that a field can become relevant immediately based on a response entered earlier on the same screen, without requiring the user to leave and return to the screen. Similarly, a constraint can reference values entered in other fields within the same field-list group.

Inherited relevance

Relevance conditions can often be simplified when fields depend on one another in a chain of skip logic. For example, suppose field_C is relevant based on field_B, and field_B is relevant based on field_A. What should the relevance for field_C be? Should field_C also have a relevance condition based on field_A? No, that would be redundant.

To illustrate this point, compare these two scenarios:

In the redundant relevance scenario for field_C, the condition based on field_A is unnecessary because it is logically inherited through field_B: a field that is not relevant is treated as blank in expressions, so if field_A does not equal 1, field_B is not relevant, ${field_B} is blank, and field_C cannot become relevant either.

Both relevance expressions for field_C will work the same way, but it is generally better to keep relevance expressions as simple and concise as 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.