List validation rule – restrict a field to a fixed list of values¶

A list validation rule allows only the values of a list in a field and offers exactly these values for selection. This page describes its settings and behaviour. It is intended for administrators who configure business rules.

1. At a glance¶


Purpose	Accepts only values from a fixed list and offers them in drop-downs, list boxes, radio buttons and button groups
Typical use	Status, priority, category, any small set of codes that rarely changes
Related	Lookup validation rule (values from records of another entity), Expression validation rule

If the values change often or need further details (a description, a manager), maintain them as records of an entity and use a lookup validation rule instead.

2. Settings¶

Setting	Meaning	Default / required
"Field"	The field whose values are restricted	required
"Valid values"	The allowed values, one per text box. Type a value into "New value" and press "Add" (or Enter); the minus button removes a value. A value that is already in the list, even with different upper and lower case, cannot be added again.	required (an empty list rejects every value)
"Condition"	Optional condition. "The rule only applies while this expression evaluates to true. Without an expression it always applies."	empty – the rule always applies
"Disabled"	The rule does not apply	off

Plus "Display Name", "Description" and "Tags" (see Business rules).

3. Behaviour¶

Checking a value¶

The value is checked when it is set, like with every validation rule. A value that is not in the list is not kept: the field gets its previous value back, without a message.
The comparison is on the value as text and ignores upper and lower case: high is accepted for the valid value High. The field keeps the value as it was set, so high stays high. Selection fields still show the value as picked.
Empty values are always accepted. Use a required for save rule to demand one.
Several validation rules on one field are alternatives: the value is accepted as soon as one applicable rule accepts it.

Offering values¶

Input fields of the field that show a selection (drop-down, list box, radio buttons, button group) offer the valid values in the order you entered them. Enter them in the order users should see.
If several list or lookup rules apply to the same field, their values are offered one rule after the other; a value offered by two rules appears once. To sort across rules, use the sorting setting of the input block (see Forms).

The condition¶

While the "Condition" is true, the rule checks the field and offers its values.
While it is false, the rule is ignored completely: its values are not offered and it does not check anything. If no other validation rule applies, the field accepts any value.
A condition that does not return true or false, or whose expression no longer exists, is treated as true – the rule applies. This prevents a broken condition from switching the check off unnoticed.

4. Examples¶

Priority. Entity Ticket, "Field" = Priority, "Valid values" = Critical, High, Medium, Low. The drop-down shows the four values in exactly this order; the value Urgent from an import is rejected.

A field with a different meaning per type. Entity Group, field Code:

Records	Rule
Type = "Cost centre"	List validation rule with the four cost centre codes, "Condition" = Type equals `Cost centre`
Type = "Project"	Lookup validation rule on the project entity, "Condition" = Type equals `Project`
every other type	no rule – any value is accepted

Do not merge both cases into one list: that would accept project codes for a cost centre.

5. Limitations¶

Values that already exist are not checked again when the list or the condition changes – also not when a change of another field makes the condition true. They stay until the field is set again.
The list holds texts. For a number or date field, enter the values the way the field shows them as text; in our assessment a lookup or expression validation is easier to maintain there.
Rejections are silent.