Field behavior conditions

Field behavior conditions are boolean expressions configured directly on a field of an entity definition. They decide, per operation, whether the field is shown, whether it must have a value, and whether it accepts changes. They share the expression language described in Syntax and types and are validated through the shared rule-expression endpoint described in Rule expressions.

The three conditions

Setting	When the condition is TRUE	Default when empty	Outside its operation mode
VisibleWhen	The field is shown.	Visible	Hidden
RequiredWhen	The field must have a value.	Optional	Optional
EditableWhen	The field accepts changes.	Editable	Read-only

An empty VisibleWhen or EditableWhen defaults to true within its operation mode; an empty RequiredWhen defaults to false. The literal TRUE in RequiredWhen means always required — definition API responses show it as "RequiredWhen": "TRUE"; other values are conditional expressions.

Visibility and editability are not access-control rules. Field permissions can still hide or protect a field regardless of these conditions, and VisibleWhen must not be used to conceal sensitive data from an otherwise authorized caller.

VisibleWhen also does not control declarative mutation effects. Use the effect’s ApplyWhen condition when a value-copy candidate should become active or inactive. Hiding a field never deletes its stored value, while an effect-owned target may fall back or clear under the separate mutation-effect ownership rules.

Operation modes

Each condition has a paired operation mode that controls when it is evaluated:

• CreateAndUpdate — evaluated for both new and existing records;
• Create — evaluated only while a new record is created;
• Update — evaluated only while an existing record is edited.

Outside its mode a condition contributes its inactive value: VisibleWhen is false, RequiredWhen is false, and EditableWhen is false. This makes EditableWhen = TRUE with mode Create a create-only field: the value can be supplied initially, the form treats it as read-only later, and the server rejects an update attempt. Likewise VisibleWhen = TRUE with mode Update hides the field on create and shows it on edit.

Reading Operation.Mode

The expression itself can read Operation.Mode, whose value is 'Create' or 'Update':

Operation.Mode = 'Update' AND Status = 'draft'

Prefer the operation-mode setting for a simple create-only or update-only rule; use Operation.Mode when operation awareness is part of a larger condition.

Expression profile

A field behavior condition can use:

• fields of the same record and exactly one direct Reference hop (Customer.IsBlocked);
• Operation.Mode, with value 'Create' or 'Update';
• the shared operators — comparisons, AND/OR/NOT, text operators, IN, NOT IN, null/empty checks.

Not supported: variables (@today is not available here), function calls, Classifier fields, the BETWEEN range operator, child-table traversal, inverse-reference traversal, and Reference chains deeper than one step. Write a range as >= low AND <= high; BETWEEN is available only in statements and validation rules (see Availability by surface).

For a child-table field, the condition can use fields of that child row but cannot traverse a Reference.

In generated Forms, Moltaro obtains a referenced value such as Customer.IsBlocked from the same server-owned context used by every Reference picker. Existing records request the required include automatically; a newly selected candidate returns the declared projected values with the selection. This works even when the Reference has no Reference Eligibility rule.

VisibleWhen:  CustomerType = 'company'
RequiredWhen: Status IN ('approved', 'completed')
EditableWhen: Status = 'draft' AND Locked = FALSE

Status = 'draft' OR Amount IS NULL
(Amount > 10 AND Status IN ('active', 'pending')) OR Name STARTS WITH 'VIP'

Server-side enforcement

Requiredness and editability are enforced by the server as well as the generated form. On save, a missing value for a field whose RequiredWhen evaluates to TRUE fails the request, and a change to a field whose EditableWhen evaluates to false is rejected — an API request cannot bypass the conditions by skipping the form.

If a saved expression is no longer valid for the current schema, the server returns a localized configuration error and does not open the Form with an invented fallback result. Fields or referenced values hidden by the caller’s permissions remain undisclosed and make the affected condition false.

Validating expressions

Field behavior conditions are validated by the shared rule-expression endpoint, POST /api/workspace/admin/entity-definitions/{entityDefinitionId}/rule-expressions/validate, with ContextType FieldBehavior and ExpressionType Condition. See Rule expressions for the shared validation contract and the neighboring condition surfaces, and Syntax and types for literals, comparison semantics, and operator details.