Administer > Administer Service Management > Studio > Processes and Rules > Studio business rules > Validation rule examples

Validation rule examples

The following examples demonstrate how to formulate rules for each of the validation rule templates:

Define field as mandatory

The only parameter in this rule template is field. Select the required field from the drop-down list. When the rule runs, the field becomes a mandatory field and it is indicated with a red asterisk on any forms on which it appears.

Example: There is a rule in Change Management called descriptionMandatory which sets the Description field as mandatory. When the rule runs, the Description field on the Change form is a required field.

Define field as read-only

The only parameter in this rule template is field. Select the required field from the drop-down list. When the rule runs, the Read Only property is marked as selected for the selected field.

Example: In Change Management, you can define a rule to set the ImpactScope field to read-only. When the rule runs, the Impact field on the Change form is not editable.

Validate expression

  1. For the expression parameter, enter an Expression Language phrase that returns a boolean value. For a full list of Expression Language functions, see Expression Language functions and syntax.
  2. For the error message parameter, enter an error message in the relevant languages.

Example: There is a rule in Change Management called CanCreateEmergencyChange which evaluates the expression ${current_user.IsPermitted('Can-Create-Emergency-Change()')}. The Expression language phrase returns a boolean value based on whether the current user has permission to create an emergency change. For the error message, enter: User is not permitted to create emergency Change, which is returned when the expression evaluates as false.

Validate no collisions

Caution It is possible to create a simple rule using this template without the "If...Then" option and the expression parameter. However, such a rule would run every time a change record is saved (if defined in After change), and on every added association (if defined in Before adding relationship), likely having a materially adverse effect on performance.

It is therefore recommended that you configure this rule template by always including an expression parameter.

  1. The value for the expression parameter depends on the detection required:

    • Check for collisions with all changes

      To check for scheduling collisions with all changes, select a matching start and end time. For example, to check for collisions of Scheduled start time and Scheduled end time, type:

      ${current_update.ScheduledStartTime.IsChanged || current_update.ScheduledEndTime.IsChanged}

    • Check for collisions with changes affecting same device

      When you check for collisions with changes that affect the same device (or devices) that the current change affects, you need to add two business rules: one to the After change section of the Change > Processes and Rules tab, and one to the Before adding relationship section. For example, to check for collisions of Scheduled start time and Scheduled end time, and for collisions with changes affecting the same device, type:

      • In the After change section, type:

        ${current_update.ScheduledStartTime.IsChanged || current_update.ScheduledEndTime.IsChanged}

      • In the Before adding relationship section, type:

        ${current_association_update.association_name == 'DeviceAffectedByChange'}

  2. For the start time parameter, select a suitable start time field. For example, Scheduled start.

  3. For the end time parameter, select a suitable end time field. For example, Scheduled end.

  4. For the changes parameter, select:

    • All changes to detect scheduling collisions with all changes.
    • Changes affecting involved devices to detect device collisions.

    Note This field displays only for the rule in the After Change section of the Change process.

  5. For the filters parameter, select to filter the change records that the business rule is applied to.

  6. For the start time field and end time field parameters, select a suitable start time field and end time field.

    The business rule compares the start time to end time (as determined above) of the current change record being worked on, with the start time field to the end time field of other active changes.

    For example, you might have the following settings:

    • start time - Scheduled start

    • end time - Scheduled end

    • start time field - Scheduled DT start

    • end time field - Scheduled DT end

    The business rule then detects change collisions between the Scheduled start and Scheduled end of the current record being worked on, with the Scheduled DT start and Scheduled DT end for all other active changes.

  7. When the rule runs, it detects change collisions according to how the rule is configured. For more information, see Change collision detection.

Note This validation rule is for Change Management only.

Validate that field is in list

  1. For the field parameter, select the required field from the drop-down list. Only fields of logical type Enum are available.

  2. For the list parameter, select one of the following options:

    • Select data. Select an item from the drop-down list.
    • Expression Language. Enter an Expression Language phrase that returns a value matching the type of the selected field.

    Click the Expression Language button to toggle between these options. When the button is selected (green), the field is in Expression Language mode. When it is not selected (white), the field is in Simple mode. For a full list of Expression Language functions, see Expression Language functions and syntax.

    To select multiple values, click Add item to open another box.

  3. When the rule runs, it verifies that the value of the selected field is included in the list.

Example: The following rule is used to restrict the process from proceeding unless the status of the request is In Progress or Suspended:

Status is selected as the field parameter, and the following collection is entered as the list parameter, forming the list of required values:

(RequestStatusInProgress, RequestStatusSuspended)

Validate that field is in range

  1. For the field parameter, select the required field from the drop-down list. Only fields of a numeric or date/time type are available.

  2. For the from and to parameters, select one of the following options:

    • Select data. Select the date and/or time using the calendar or enter it manually (for non-date/time numeric values).
    • Expression Language. Enter an Expression Language phrase that returns a numeric or date/time value.

    Click the Expression Language button to toggle between these options. When the button is selected (green), the field is in Expression Language mode. When it is not selected (white), the field is in Simple mode. For a full list of Expression Language functions, see Expression Language functions and syntax.

  3. When the rule runs, it verifies that the value of the selected field is within the range bounded by the from and to values.

Example: In Incident Management, if there is a priorityNumber field which contains a numeric value, the following rule is used to restrict the process from proceeding unless the priority is between 1 and 3:

priorityNumber is selected as the field parameter, 1 is entered as the from parameter, and 3 is entered as the to parameter, forming the required range of the field.

Note All of the rules can be formulated with the "If...Then" option, which includes an expression parameter for the condition. Make sure to enter an Expression Language phrase that returns a boolean value.

Related topics