Collections and related records

A collection condition checks the items of a collection: the rows of a child table, the records that reference the current record (an inverse reference), or the collections of those records in turn. Write it with one of four forms:

Form	Result
EXISTS collection WHERE (predicate)	TRUE when at least one item matches. An item whose predicate is unknown does not match.
ANY collection WHERE (predicate)	TRUE when an item matches. Unknown when no item matches but one is unknown.
ALL collection WHERE (predicate)	TRUE when every item matches. Unknown when no item fails but one is unknown.
COUNT(collection) <comparison>	Compares the number of items, for example COUNT(Items) > 0.

Keywords are not case-sensitive. A field named Any, All or Exists still reads as a field; the keyword form needs a collection and WHERE.

How ANY and ALL decide

Only a definite TRUE makes a condition match. A missing value makes a comparison unknown, and an unknown item can leave the whole result unknown:

Item results	ANY	ALL
No items	false	true
true and false	true	false
true and unknown	true	unknown
false and unknown	unknown	false
only unknown	unknown	unknown
all true	true	true
all false	false	false

ALL of an empty collection is TRUE. To require at least one item, write the requirement explicitly:

COUNT(item.Assemblies) > 0 AND ALL item.Assemblies WHERE (State = 'built')

EXISTS keeps its existing behavior: it never returns unknown. Saved expressions that use EXISTS behave exactly as before; choose ANY when an unknown item should not count as a non-match.

A condition is invalid, not false, when it reads something that is no longer available. Examples are a removed field, a removed Board or Workflow binding, or a module that is disabled. Moltaro reports an invalid condition as a diagnostic and never treats it as a business result. Every item takes part in this check, so one invalid item cannot be hidden by another item that already decides the result.

Paths inside a predicate

Inside WHERE (…), fields are read from the current item. Write them without a root, for example State, not item.State. A predicate can use the item’s:

• ordinary fields;
• Reference paths, for example Supplier.Code, including the record the collection belongs to, for example Order.Code;
• collections of its own, which nest: ALL Components WHERE (…) inside an Assemblies predicate reads the components of the current assembly, never a root collection with the same name;
• configured Board and Workflow facts of the item, for example context.production.isPresent or context.production.status.Key. Facts use the exact configured binding key; Moltaro never picks a Board on its own when a record has several.

ANY item.Assemblies WHERE (State = 'built' AND ALL Components WHERE (State = 'done'))
ALL item.Assemblies WHERE (context.production.status.Key = 'done')
ANY item.Assemblies WHERE (ANY Supplier.Contracts WHERE (Active = TRUE))

Collection predicates nest at most three levels. A deeper predicate is rejected with a complexity diagnostic; Moltaro never drops items to make a collection fit a limit.

Where collection conditions are available

Surface	EXISTS / COUNT	ANY / ALL	Nested collections and related facts
Entity and Board Item Security Statements (admitted collections only)	✓	✓	✓
Workflow activation preconditions	✓	✓	✓
Workflow permission rules for starting processes and answering User Input	✓	✓	✓
Entity Statements (direct child tables)	✓	✓	—
Board Statements (direct collections)	✓	✓	—
Board Status Security, field behavior, presentation, validation rules, mutation effects, Reference Eligibility, Task completion eligibility	—	—	—
Calculated fields (use aggregates instead)	—	—	—

Surfaces without collection conditions reject them at validation time. Workflow activation preconditions are actor-independent business conditions: they cannot read user, @currentUserId, HAS_ROLE or RESPONSIBLE. Security Statements and Workflow permission rules have a different actor-aware profile. Their security forms are used outside collection predicates; inside a predicate, use only the published item fields, collections and facts. See Security and Workflow conditions.

In the expression editor

• Collection condition inserts ANY, ALL or EXISTS for a chosen collection and places the cursor inside the predicate. The editor offers only the forms the surface accepts.
• Inside a predicate, completion suggests the fields, references, nested collections and facts of the current item.
• Language reference explains empty collections, unknown values and invalid dependencies. Its examples use your own related collections and fields: an ANY example, the non-empty ALL pattern, and, when an item has collections of its own, a nested example such as ANY item.Assemblies WHERE (COUNT(Components) > 0 AND ALL Components WHERE (State IS NOT NULL)). Every example is checked against your schema before it is shown, so a copied example validates in the editor that offered it. Surfaces without collection conditions show none.
• Diagnostics point at the exact part of the expression, also inside nested predicates.

Example: production readiness of an order

An Order has Assemblies (an inverse reference). Each Assembly is placed on the production Board through the production fact binding. Use this condition when the Order is ready only if it has assemblies and all of them have reached the done status:

COUNT(item.Assemblies) > 0
  AND ALL item.Assemblies WHERE (context.production.status.Key = 'done')