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

Additional properties and considerations

In part 2 of this guide on constraint expressions you'll learn even more about constraints to help you get the most out of SurveyCTO's field validation capabilities.

Constraint messages

Field constraints have an accompanying property, constraint message, which was mentioned in part 1 of this guide. A constraint message is a message that flashes on screen for a few seconds when a constraint expression is violated. If you don't specify your own, the default constraint message in English is "Sorry, this response is invalid!". The default won't always be helpful to the user though. The purpose of a constraint message is to make the problem clear to the user so that they know how to fix it, so providing a good custom constraint message is important.

Keep in mind that a constraint message flashes on screen for a limited amount of time, so there is a natural limit to some degree, as to how complex the problem you're trying to solve with a constraint should be. To solve the problem, the user must be able to understand it and the solution.

Note that constraint messages cannot include dynamic references to values stored in a field ("You said ${answer_from_earlier} before, this is not correct" would not work). A reference to a value in the field in a constraint message will appear in a form with field's name, $ sign and curly brackets like you see it in the online designer or the spreadsheet template. You could compensate by making a general reference to the value in the constraint message and a specific one in the field's hint.

Allowable exceptions

Given that integer and decimal fields can take only numeric inputs, other types of responses like "don't know" and "refused" must be captured in different ways. To capture such a response in a numeric field, you'll need to use special coded values that represent those answers. Our recommendation would be to use special coded values outside the true range of possible answers, so these responses are easily identified as special codes in the data in contrast to true values in range. In the example above, -99 is used to represent "don't know" (a person cannot be -99 years old, so this is out of range). We also recommend that you try to standardize your special codes across integer and decimal fields (maybe in choice lists too), and make the special codes clear to the user in either the label or hint text for the field.

You will always include exceptions to the rule in constraint expressions by using the "or" logical operator. As in the example in the first part of this guide, -99 is allowed by adding "or . = -99" to the end of the expression.

When to add constraints

Constraints should be used often, wherever they make sense, even if they only guard against unlikely, or obviously erroneous responses. If you can anticipate and prevent an error, do it because it will save you time later, cleaning and correcting data. This will free you up to focus on more important things. Even if you have no idea what the logical range for a numeric value is in advance (e.g. household income for the past year), add some sort of constraint, even if it just prevents negative numbers and other values that are wildly out of range. In some cases, a constraint simply won't make sense but rather think it through instead of assuming that there is no way to constrain a response.

Timing and logic

Constraints, like other expressions in SurveyCTO, evaluate between screens. With a single field on a screen, when you attempt to move to the next screen, the constraint will be evaluated and the constraint expression is true, you will be able to pass and if false, you will be blocked from moving to the next screen.

However, when multiple fields inside a group with the "field-list" appearance option have constraints, only one field's constraint will be displayed at one time. The top-most field in the list should have their constraint message appearing first, moving down the list. For constraint messages to be most useful in a "field-list" group, make sure that constraint messages make it clear which field's answer is problematic (i.e. name the question).

Also, take care to test any set of constraints with dependencies on other fields inside the same repeat group. As above, expressions evaluate between screens, so only when you try to move forward to the next screen, do you see the results of a constraint being evaluated. In certain complex constraint expression interactions between fields inside the same field-list group, changes to values stored in fields may not register unless you return to the previous screen and try again to move to the next screen (e.g. in the case you have a constraint based on the sum of integer fields inside the current "field-list" group).

Self-reference syntax

In SurveyCTO expressions, to refer to the value in the current field, one can use the shorthand of a full stop or period ("."). This is in place of calling a value in a field, enclosing the name of that field in a $ sign and curly brackets (e.g. "${fieldname}"). Review the example constraint expression in part 1 of this guide and notice "." in the expression. An equivalent expression might more redundantly (but validly) be written as follows if the field's name was "age":

(${age} >= 18 and ${age} < 100) or ${age} = -99

However, it is redundant to use the name of a field in its own constraint expression, when it can rather be:

(. >= 18 and . < 100) or .= -99

Self-referential syntax is generally a feature of constraint expressions only. Referring to the value stored in the current field in relevance, calculations or choice_filter expressions doesn't make logical sense and would result in an invalid form definition.

To see working example constraint 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.