B: The rule will be fired if a condition is true.

Behaviour: When a condition specified for any attribute (of the rule's business object type) is met, than the rule is triggered. This represents more of a 'status' rather than 'action' type of triggering because just the fact that the condition is 'true' is enough to trigger the rule. (Unlike trigger A where the condition must be met AND the 'trigger' attribute must be changed.) Consequently the rule will be triggered not only when an attribute change resulting in fulfilling the condition happens, but also e.g. when the editor is opened.

For example, the rule says that attribute Y is displayed only when value of attribute X is higher than 100.

Then the following two scenarios are possible with trigger type B in use:

• Before a closed editor gets opened, the condition is evaluated and attribute Y is or is not displayed depending on the result.

• The editor is already opened with attribute Y present / not present. The value of attribute X changes, the condition gets evaluated and attribute Y is dynamically hidden / displayed depending on the evaluation result and the initial status.

Trigger B "cleans after itself": When the value of attribute X changes back to a non-triggering state, the changes caused by triggering the rule are reset, e.g. a dynamically displayed attribute is hidden again.
Note that this behaviour applies only to trigger B (the triggering is based on achieving and leaving a value), triggers A and C do not "clean after themselves" (the triggering action is not "taken back").

Another important aspect is that unlike trigger A (and C) which happen only when the editor is opened, trigger B does not require the editor to be opened and the action (e.g. a calculation) happens whenever needed.

This type of triggering is typically used for view and calculation rules.