Syntax and types

This page describes the shared syntax of Entity Definition expression surfaces. Board Statements reuse the lexical core but intentionally extend or override parts of the operator, temporal, variable, collection, and null semantics described below. For Board-owned expressions, use the Board Statement profile as the authoritative contract before applying any rule from this page.

Literals

Kind	Examples	Notes
Number	1, 100, 12.50	Decimal separator is always . (invariant culture).
String	'active', "VIP"	Single or double quotes; escapes \n, \r, \t, \\, \', \". Not available inside calculated-field arithmetic.
Boolean	TRUE, FALSE	Case-insensitive.
Null	NULL	Case-insensitive.
Classifier category	CATEGORY('product-area', 'operations', 'platform')	Statements and validation rules only. The first key identifies the Classifier Catalog; the remaining keys are the category path.

Field references

• A bare identifier references a field of the record by its key: Qty, Status, DueDate. Rule and validation expressions resolve field keys case-sensitively — qty does not match Qty. Calculated-field expressions normalize same-table field keys, so qty and Qty resolve to the same field there.
• A dotted path reads one step through a reference field: Customer.DisplayName. Only first-level paths are supported; deeper chains such as Customer.Owner.Department are rejected.
• Calculated-field expressions are same-table only and do not accept dotted paths.

Operators

In precedence order, lowest first (parentheses override as usual):

Level	Operators
Boolean	OR, then AND, then NOT
Comparison	=, ==, !=, <>, >, >=, <, <=
Text	CONTAINS, STARTS WITH, ENDS WITH
Membership and range	IN (a, b, …), NOT IN (a, b, …); BETWEEN low AND high (statements and validation rules only — see Availability by surface)
Null and empty	IS NULL, IS NOT NULL, IS EMPTY, IS NOT EMPTY
Arithmetic (calculated fields only)	+, -, *, /, unary +/-

Keywords and operators are case-insensitive: and, And, and AND are the same operator.

Board Statements additionally support BETWEEN, typed date/time and duration arithmetic, and the exact function set published by their authoring profile. They do not inherit calculated-field arithmetic merely because the operator tokens are the same.

Null and empty semantics

• IS EMPTY treats NULL, a blank string, and an empty collection as empty.
• Equality: two null values are equal; comparing null with a value orders the null as the smallest value.
• Prefer IS NULL / IS EMPTY over = NULL — they state the intent directly.
• Classifier equality, inequality, IN, and NOT IN never match a null value. Use IS NULL or IS NOT NULL explicitly for a Classifier field.

Board Statements use three-valued null propagation: ordinary equality, ordering, text, membership, and arithmetic with NULL do not become TRUE; use IS NULL, IS NOT NULL, IS EMPTY, or IS NOT EMPTY explicitly. The Board Statement null contract therefore overrides the Entity Definition comparison rules above.

Classifier category values

Statements and validation rules use a portable typed literal for a Classifier category:

CATEGORY('catalog-key', 'root-key', 'child-key')

The first argument is the stable Catalog key. The remaining arguments are the stable node keys from the Catalog’s logical root to the selected category. Display names and rendered breadcrumbs are not part of the comparison. The logical root itself is not a value, while a stored non-leaf category is valid.

Classifier fields support =, !=, IN, NOT IN, IS NULL, and IS NOT NULL. Field-to-field equality or inequality is valid only when both fields use the same Classifier Catalog. Field behavior, presentation, and calculated-field expressions do not support Classifier values.

Value comparison rules

• Numbers compare across integer/decimal representations, including numeric strings.
• Dates and times compare across date, date-time, and parseable string values (invariant format such as 2026-07-25).
• Strings are trimmed before comparison and compared ordinally — string comparison is case-sensitive.

Variables

Statements and validation rules support runtime variables; field behavior and presentation expressions do not.

Variable	Meaning	Available in
@currentUserId	Identifier of the acting user	Statements, validation rules
@today	Current date in the workspace time zone	Statements, validation rules
@today+7d, @today-7d	Date offset by a signed number of days	Statements, validation rules

Example: DueDate BETWEEN @today AND @today+30d.

Board Statements expose @today, @now, and event-only @currentUserId under their own eligibility rules. See Board Statement date and time values and the server-owned authoring profile; this Entity Definition availability table does not describe the Board surface.

Availability by surface

Most Entity Definition condition surfaces share comparisons, AND/OR/NOT, the text operators, IN / NOT IN, and null/empty checks. A few constructs are gated to specific surfaces and are rejected at validation time everywhere else — most notably BETWEEN, which is not available in field-behavior or presentation conditions even though IN / NOT IN are.

Construct	Field behavior	Presentation	Statements	Validation rules	Calculated fields
BETWEEN low AND high	—	—	✓	✓	—
Variables (@today, @currentUserId)	—	—	✓	✓	—
CATEGORY(...) classifier literal	—	—	✓	✓	—
MATCHES(value, "regex")	—	—	—	✓	—
EXISTS / COUNT(child) child-table forms	—	—	✓	—	—
Numeric / aggregate functions (IF, COALESCE, ROUND, SUM, …)	—	—	—	—	✓
Text functions (trim, upper, lower, coalesce)	—	template only	—	—	—

Field-behavior and presentation conditions are operator-only: they accept no function calls, and a range must be written as >= low AND <= high. The text functions apply only inside presentation templates. See the Function reference for the per-surface function catalog.

Error reporting

Expressions are parsed and bound against the entity schema when you save or call a validation endpoint. Rule-expression and validation-rule errors include a message, the offending token, the resolved field path where relevant, and a stable error code — enough to locate and fix the error programmatically. Calculated-field errors return the request field, localized message, and stable code. Board Statement diagnostics also return an exact source offset; the authoring UI renders it as a one-based line and column.