Logic overview

The Automation & logic group of an entity definition has four tabs. They hold different kinds of logic, and knowing which is which saves time:

Tab	What it holds
Mutation effects	Declarative field copies configured without code.
Logic	Workspace C# functions bound to this entity (validation, before-save mutations, triggers, actions).
Validation	Object-level rules written in the Moltaro expression language (DSL).
Object context facts	Module facts (Boards, Entitlements) materialized onto records.

Mutation effects

Configuration-only effects that copy values into fields during create and update. Each effect has a target field, a same-record or Reference source path, trigger fields, an apply-on mode (create, update, or both), an assignment mode (set-if-empty or overwrite), and an optional Apply when condition.

Always is the default. Never keeps the effect configured but excludes it from the current save. A typed expression can read fields on the current record, Operation.Mode, and one Reference hop, for example:

UsePrimary = TRUE AND Product.Price > 0

Fields read at the root of the condition act as additional triggers. Changes to the referenced Product do not start a bulk backfill; the condition is re-evaluated when the order is created, edited, or previewed in its Form.

When multiple set-if-empty effects target the same field, Moltaro uses their global order. If the current winner becomes false, the next active non-empty source becomes the fallback. If none remains, Moltaro clears the value only when it is still owned by effects; a user or Package SDK value is preserved. If a Reference or field cannot be read safely, the previous value is retained and no lower fallback is chosen.

VisibleWhen is different: it only controls whether a Form shows a field. A hidden field is not automatically cleared and visibility never substitutes for ApplyWhen.

Logic (workspace C#)

A diagnostics view of the C# functions bound to this entity from the workspace operation project: Validation functions that block invalid saves, Calculations (before-save mutation functions that normalize or derive fields), and Triggers (asynchronous post-commit handlers). Create actions scaffold C# templates and open the development studio. Authoring details live in Business logic.

Validation (DSL rules)

Object-level checks written as boolean expressions that must return TRUE before a record can be saved. Each rule has a stable key, an expression, a failure message with per-locale translations, an enabled toggle, and an order — enabled rules run in order, and the first failing rule produces the message users see.

DSL rules cover required-if conditions, numeric ranges, date ordering, pattern matching, and depth-one reference reads. They intentionally exclude inverse-reference traversal, child-table aggregates, and raw SQL; use workspace C# for those. DSL validation runs before C# business rules. The full expression syntax is documented in the expression language reference.

Object context facts

ID-only wiring that pulls module facts onto entity records: the current board item state for selected boards, or active entitlements for selected entitlement models. Configured facts become bindable columns and items on table and card surfaces and Data Explorer filters.

Evaluation order

During a save: mutation effects run first, then local calculated fields, then the record persists, then aggregate calculations refresh. Validation (DSL, then C#) gates the save itself.

Where to go next

• Presentation and statements for display-oriented rules.
• Business logic for authoring, runtime behavior, and diagnostics of C# and declarative logic.