Skip to main content

Executing Logic Against Filtered Collection Members

The problem

Aggregate expressions such as Count() support expression evaluation only. They evaluate a condition, but they don't support procedural or stateful side effects during iteration, and there is no function to write or persist a value against the iterator's context. (The CurrentContext(field) function reads a field from the root expression context, not the collection member being iterated, and can't be used to capture per-member state either.) The following is pseudocode, not valid InRule syntax, illustrating the unsupported pattern authors sometimes reach for:

// Not valid InRule syntax — illustrative only
Count(List1,
fieldA = 1
AND
SaveContextValue("List1", CurrentContext) = true
) > 0

followed by a later, separate rule trying to retrieve that saved context:

// Not valid InRule syntax — illustrative only
ReadSavedContextValue("List1", "FieldB")

There is no supported way to persist a generic entity reference like CurrentContext mid-expression and retrieve it across rule boundaries this way.

Instead of trying to capture and store iterator context from within an aggregate expression, use the Execute Member Ruleset action to run logic directly inside each matching collection member's own context, where its fields are natively accessible.

Step 1 — Create an explicit ruleset in the member entity

In the entity type that the collection (e.g. List1) contains, create an explicit ruleset, for example ValidateMatchingMember. Author the logic directly against that member's fields. No context persistence is needed, since the ruleset executes inside the member itself.

Step 2 — Call it with Execute Member Ruleset from the parent

In the parent entity's ruleset, add an Execute Member Ruleset action:

  • Target collection: List1
  • Target ruleset: ValidateMatchingMember
  • Filter: fieldA = 1

The engine iterates List1 and, for each member matching the filter, executes ValidateMatchingMember directly in that member's context. No Count() and no context persistence or retrieval is required.

Step 3 (optional) — Wrap it in a Vocabulary Expression Template for reuse

To reuse the pattern across multiple rules, create an Execute Member Ruleset Vocabulary Template with a placeholder parameter (e.g. $filterCondition$) so authors can write business language such as:

Validate List1 members where $filterCondition$

and supply a different filter condition per rule.

Why this is cleaner

Attempted patternExecute Member Ruleset pattern
Count() filter tries to persist CurrentContextFilter is just the Execute Member Ruleset filter
Separate rule tries to retrieve saved contextTarget ruleset runs inside the member — fields are already in scope
Not supported (aggregate expressions are stateless)Natively supported by the rule engine