Develop > Process Designer Tailoring Best Practices > Best practices for using the condition editor

Best practices for using the Condition Editor

The Condition Editor enables you to build a condition without any knowledge of programming languages. Conditions always evaluate to True or False. When a condition evaluates to True, the system runs the rule or applies an action that the condition controls. This section provides information about the best practices of using the Condition Editor.

Use cross-table fields in Condition Editor

Cross-table fields, which are defined by a reference record, are the fields of related tables. The table relationship is maintained by the Relation Manager in Service Manager. You can use cross-table fields in Condition Editor to configure various conditions.

To configure the cross-table fields as part of a condition, you can select the cross-table field names in Condition Editor. However, using cross-table fields might be time-consuming because the system needs to prepare the variable of the reference record at run time. For example, an incident record has the field “Contact”, which refers to the Contact record. You can configure the Rule condition to use the Location of the Contact record directly, as shown below:

At run time, the expression is evaluated to something as follows:

location in $L.file.contact.name.contacts.contact.name="Asia"

The variable $L.file.contact.name.contacts.contact.name is prepared by the rule engine.

If you use the Condition in your own scenario, be sure to invoke the JavaScript method below at run time before evaluating the condition expression, which automatically prepares the cross-table reference record for you:

lib.Workflow.initVarForCondition(conditionXml);

Use user option fields in Condition Editor

You can configure the User Option fields as part of a condition by specifying the names and values of the user option fields in Condition Editor.

However, using the user option fields might be time-consuming because the system needs to prepare variables for the user option fields at run time. For example, you configure to use the User Option as part of a task condition in Task Planner as follows:

At run time, the expression is evaluated to something as follows:

$L.UO.EmployeeType="Regular"

The variable $L.UO.EmployeeType is prepared by the system.

If you use the condition in your own scenario, make sure that you invoke the JavaScript method below at run time before evaluating the condition expression, which automatically prepares the user option variable for you:

lib.Workflow.initVarForCondition(conditionXml);

Note: The instance data of a user option is stored as a string value in the file userOption, and thus at run time, when the user option value is evaluated, it is also treated as a string value.