Check existence
Rule types – Abstract
Executes a Search for entities of a certain Class on the Lobster Data Platform / Orchestration database and checks if it produces at least one match.
A Check existence rule executes a Search for entities of a certain Class on the Lobster Data Platform / Orchestration database and checks if it produces at least one match.
►IMPORTANT◄ In a similar way to the Search builder, the search can only return entities of the class for which read access is granted in the context of the current session.
►WARNING◄ It is not recommended to use this type of rule in Association criteria to avoid performance issues linked to frequent execution of the configured database searches. Association criteria of type 'Logical component' are exceptions to this rule, since they are only executed selectively, similar to validating rules of Event handling and therefore much less frequently.
The definition of a search involves the following elements (see also Search API):
The selection of a Class defines the type of entity so search for.
Entities of other types may be included in the search via Joins, if required.
The Where condition defines Restrictions for the search, based on properties of any involved entity type.
►NOTE◄ Projections configured to define in the Restriction refer to the searched class and not to the currently valid input object in the context of the Check existence. If the Restriction is supposed to include data from this context, it can be accessed via the Variable entity. Of course, other variables can be included if needed, to include 'more remote' contexts, if needed (beyond a Für jeden Eintrag wiederholen (Schleife)) or an Execute with event action).
Configuration example:
The Validating rule of an event handler should trigger certain event actions if the Company of session owns inactive user accounts.
This search refers to the Class 'User', without involving any Joins.
The Where condition defines a conjunction (AND) of two criteria:
The first Field restriction accepts users whose 'Owner' (ownerId) matches the ID (id) of the Company of session.
The second Field restriction accepts users for which the flag 'Active' (active) is unchecked (false).
This rule is passed if the intersection of both Restrictions is not empty. In that case, event actions might produce a warning message or open a certain view, featuring details of inactive users.