Rules and calculations

Expressions are trees built from four kinds of node, composed by choosing an operator and filling its inputs. Inputs can themselves be operators, field references, or constants. There is no text to type; the editor only offers operations the engine can evaluate.

Show, Require, and Validate treat the expression result as a boolean:

Comparison operators return true or false. They work on numbers and on date strings — no need to pick a different operator for dates.

These check whether a question has any answer at all, regardless of the value.

All maths operators return blank when any input cannot be converted to a number. Division and remainder by zero return blank rather than Infinity or NaN.

Date operators accept YYYY-MM-DDstrings (what date fields store) and full ISO datetime strings. All arithmetic runs in UTC so server recomputation agrees with the browser regardless of the respondent's timezone.

These work on multi-choice answers (a list of selected values) and on repeating section answers (a list of per-entry sub-form responses).

When your option list carries extra data in its metadata columns — a UDISE code on a school list, a district code on a village list — a Calculate rule can copy that data into a read-only field the instant the respondent picks an option. No second dropdown, no transcription error.

Example: lookup("ng-schools", school_name, "udise_code") — the moment a school is selected, its UDISE code fills the read-only field. The second argument (school_name) must be a plain field reference, not a computed expression. This restriction is enforced at publish time.

A form bound to a record type can read an answer given on another form for the same subject. A follow-up visit form can pre-fill the district from the registration form; a score form can read the previous baseline.

The server uses the same compiled rule set stored in the immutable form version, so it reproduces exactly what the respondent saw — no drift between browser and server.

The compiler checks the complete rule set when you publish. Rules that would fail at runtime are rejected before any respondent sees the form.

The following are also caught and reported at publish time:

• Unknown operators — an operator name not in the built-in set is rejected. There is no way to inject custom code or eval.
• Unknown field keys — a reference to a question that does not exist (or was deleted after the rule was written) is caught with the offending rule named.
• Dependency cycles— if field A's Calculate rule references B and B's rule references A, publication fails and both fields are named. Detection runs across the whole rule set, not rule by rule.
• Lookup restriction — the second argument to lookup() must be a bare field reference. An expression there would require multi-pass evaluation, which the engine does not support.

The rule editor offers ready-made starting points. Each template produces a valid rule that compiles as-is; you then swap a field or a constant to match your form.

The builder has two ways to make questions conditional: Conditional Logic (the simpler panel) and Rules (this page). Both can show or hide questions, but they are not duplicates.

Use Conditional Logic for simple “if the answer is X, show Y” cases and for page-jump navigation. Use Rules when you need calculations, nested conditions, date arithmetic, lookups, or cross-form data.