It is frequently useful to embed attribute values within a Rule Statement, so that posted messages contain actual data. Special syntax must be used to differentiate the static text of the rule statement from the dynamic value of the attribute. As shown in Sample Rulesheet with Rule Statements Containing Embedded Attributes, an embedded attribute must be enclosed by braces {..} to distinguish it from the static Rule Statement text.

It may also be helpful to indicate which parts of the posted message are dynamic, so a user seeing a message knows which part is based on current data and which part is the standard rule statement. As shown in Sample Rulesheet with Rule Statements Containing Embedded Attributes, brackets are used immediately outside the braces so that the dynamic values inserted into the message at rule execution are enclosed withing brackets. The use of these brackets is optional; other characters can be used to achieve the intended visual distinction.

Remember, action rows execute in numbered order (from top to bottom in the Actions pane), so a rule statement that contains an embedded attribute value must not be posted before the attribute has a value. Doing so results in a null value inserted in the posted message.

Figure 1. Sample Rulesheet with rule statements containing embedded attributes
Figure 2. Rule Messages window showing bracketed embedded attributes

When an attribute uses an enumerated Custom Data Type, the dynamic value embedded in the posted rule message is the value, not the label. See the Rule Modeling Guide, “Building the Vocabulary” chapter for more information about Custom Data Types.

No expressions in Rule Statements

A reminder about the tables Usage restrictions, which specifies that the only parts of the Vocabulary that can be embedded in rule statements are attributes. No operators or expressions are permitted inside rule statements. Often, operators cause error messages when you try to save a Rulesheet. Sometimes the rule statement turns red. Sometimes an embedded equation executes as you intended, but no obvious error occurs, but the rule does not execute as intended. Remember that operators and expressions are not supported in rule statements.