Who is this article for?

Users and Administrators seeking information on rules and behaviors

While it isn't necessary for Administrators to write DXL rules, it is important to understand their purpose and how they work. 

Rules are simple calculations written in DXL. DXL is like a formula in a spreadsheet and can reference fields, roles, users, teams, orgs, workflow step/task, and special variables.

When writing a rule, the DXL rule must evaluate to true for associated field behaviors to be applied. Consider a rule a condition when something is true.

For example:

• Make the “Date Implementation Completed" field invisible when the workflow task is before Implementation
• Make the “Date Implementation Completed" field required when the workflow task equals Implementation
• Make the “Date Implementation Completed" field non-modifiable when the workflow task is after Implementation

Notice in the examples above to implement a set of requirements that multiple rules may be necessary to test for different conditions. Rules are often reused in multiple parts of a module.

For example, a rule that checks for when the workflow is “closed" may make multiple fields non-modifiable and disable the save button.

Consider the following examples:

1. When the workflow step is equal to “screen"
2. When the workflow step is equal to or greater than “screen"

In example 1 above, only the “screen" workflow step would make the rule true. In example 2, any workflow step including the “screen" step would make the rule true.

Rules can, and often do, have many associated behaviors. A rule could therefore fire multiple times depending on its behaviors, since not all behaviors fire at the same time. For example, visibility conditions are executed when an object is opened, but email notifications are only executed when Save or Submit is clicked.

Every module comes with an ALWAYS rule that cannot be deleted. The ALWAYS rule is always true. For behaviors that will always be applied, the ALWAYS rule will be used.

Rule examples - in layman's terms (not DXL)
The text following when is the rule:

• Display a pop-up error to the user when a date greater than today is entered into the "Date of accident" field
• Skip the Management Review task when the Significance Level field equals "4"
• Make the Resolution Comments field non-modifiable when the logged-on user's role does not equal "Administrator"
• Make all fields non-modifiable when the workflow step equals "Close"

Use 'does not equal' when it makes sense
There may be times when it is best to have a rule be true when something is not equal to something else. For example, hide the Act as Assignee button when role of the logged-on user does not equal Administrator. Common syntax for 'does not equal' is != or <>.