Overview

Business Rules perform If/Then tests with and/or operators.

Disabling Business Rules

A Business Rule can be disabled without deleting it. From list view, uncheck the checkbox in the Enabled column for the Business Rule. Alternatively, uncheck the Enabled checkbox in the properties of the Business Rule.

Preventing Business Rules from Executing

It may be desirable to apply a Business Rule once, for example, assigning a Request to a first-level tech. On subsequent saves of the Request, the assigned Analyst should not be reset to the value defined by the Business Rule, in case manual reassignment has occurred.

Procedure

Go to Administration > Form Design > FORM NAME.
Click the field that has a Business Rule configuration.
Uncheck the option Ignore Business Rule Value When Creating New Request and/or Ignore Business Rule Value When Updating Existing Request.
Click the Save button .

Criteria

Problem Summary

Field Name: sys_problemsummary

This field is the short description on the Request form, and correlates to the subject line of an email, when processed as a new Request.

Problem Description

Field Name: sys_problemdesc

This criterion will be used to test the presence or absence of a defined string. Note that this can be used to process Requests that have been manually created or imported from email. In the case of email, the Request will be imported, saved, then the Business Rule will be applied.

Examples of Use

Assignment Based on a String

When an email is processed as a new Request and contains the string invoicing, the Request can be assigned to a specific Analyst.

Assignment of Request Type Based on String

A network router is configured to email a log dump. Requests containing a log dump can be reassigned to a specific Request Type, regardless of whether the Analyst set one or not, thus enforcing an internal policy.

Change Status on the Basis of Time Since Last Status Change

A ticket that is in a status of "Open" can be changed to the status to "Hold" after 2 days.

sys_changestatus_date stores the date and time when the status is changed. The criterion is sys_changestatus_date after X Days. If you choose Today, the Business Rule will trigger immediately after a status change.

Back to Contents

Status Change Date

Field Name: sys_changestatus_date

This field records the date and time when the status is changed.

Examples of Use

Escalating Status Based on Elapsed Time

This example supposes that a Request should be escalated from its initial Open status to Closed through a series of statuses indicating lapsed timeframes.

Configuration

Configure 3 Request Statuses. Note that these must be of the type Continue.
1. Awaiting User Response:
2. 2 Days no Response (same settings).
3. 4 Days no Response (same settings).
Create 3 Business Rules. Note that sys_changestatus_date must appear first in the list of criteria.
1. Status Change 1
2. Status Change 2: Change these settings:
  1. Rule Name: Status Change 2
  2. Description: If status is not changed within 32 hours, and status is "2 Days No Response", change to "4 Days No Response"
  3. Select Criteria:
    1. sys_changestatus_date after 32 Working Hours
    2. sys_requeststatus (Request Status) is 2 Days No Response"
  4. Perform these action: sys_requeststatus (Request Status) 4 Days No Response
3. Status Change 3: Change these settings:
  1. Rule Name: Status Change 3
  2. Description: If status is not changed within 40 hours, and status is "4 Days No Response", change to "Closed"
  3. Select Criteria:
    1. sys_changestatus_date after 40 Working Hours
    2. sys_requeststatus (Request Status) is 4 Days no Response
  4. Perform these action: sys_requeststatus (Request Status) Closed

Use

Open a Request. The status will be Open, assuming this is what is configured in Default Status.
Change Status to Awaiting User Response. This begins the timer. Note that the rule cannot be applied if the status is not changed.
If the End User comments within any of the three timeframes, the timer is reset. So, if the status is Awaiting User Response and 15 hours have elapsed with no comment, then the End User comments, the timer resets. If no comment then occurs within 16 hours, the first Business Rule will execute. This would be a total of 31 hours after first changing the status to Awaiting User Response.

Back to Contents

Last Comment Date

Field Name: sys_lastcommentdate

This field records the date and time when the last comment was created.

Examples of Use

Resetting Status Based on Comment During Elapsed Time

This example will change a status to Open from any of a number of escalating statuses, indicating that as the End User has now commented, the Request can be taken off the track to closure, unless the End User does not comment within the timeframe of the final status. Can be used in conjunction with Escalating Status Based on Elapsed Time.

Configuration

Configure 3 Request Statuses. Note that these must be of the type Continue.
1. Awaiting User Response:
2. 2 Days no Response (same settings).
3. 4 Days no Response (same settings).
Create 3 Business Rules. Note that sys_lastcommentdate must appear first in the list of criteria.
1. Reset Status 1
2. Reset Status 2: Change these settings:
  1. Rule Name: Reset Status 2
  2. Description: If End User comments within 32 hours, and status is "2 Days No Response", change to "Open"
  3. Select Criteria:
    1. sys_changestatus_date within 32 Working Hours
    2. sys_requeststatus (Request Status) is 2 Days No Response"
  4. Perform these action: sys_requeststatus (Request Status) Open
3. Reset Status 3: Change these settings:
  1. Rule Name: Reset Status 3
  2. Description: If End User comments within 40 hours, and status is "4 Days No Response", change to "Closed"
  3. Select Criteria:
    1. sys_changestatus_date within 40 Working Hours
    2. sys_requeststatus (Request Status) is 4 Days no Response
  4. Perform these action: sys_requeststatus (Request Status) Closed

OU Name

Field Name: euser_sys_ouname

This criterion will be used to test any of the conditions of a user-defined field against an End User's OU. Note that, in the case of a manually created Request, the Business Rule will be applied when the Request is saved.

Note that you must map the euser.sys_ouname field to the applicable LDAP field and reimport your End Users in order the populate the field so that it can be used.

Examples of Use

Reassignment Based on an End User's OU

The organization has an OU structure containing, in part, the following:

   Home
     Home Office
     Home Accounting

When an email is processed as a new Request, or an Analyst creates a Request manually, if the OU associated with the End User contains the string home, the Request can be assigned to a specific Analyst.

Back to Contents

User-Defined Fields

The following Conditions can be configured in the Select Criteria section:

Condition	Description
contains	The user-defined field includes the defined string, even if partially matched, e.g. usr_productcode contains XK72 would match both ENK-XK72 and B-XK72a.
exact	Equivalent to is. The user-defined field exactly matches the string.
does not contain	The user-defined field excludes the defined string, even if partially matched.
begins with	The user-defined field begins with the defined string, even if partially matched.
ends with	The user-defined field ends with the defined string, even if partially matched.

Procedure

Go to Administration > General Settings > Business Rules. To add a new rule, click the Add button .
The following window is displayed:
In the following example, the rule will always set the Priority to High if the End User is Elizabeth Pearson. She is considered to be a VIP and we want the High Priority regardless of what it is set to manually. Enter the rule name, a short description and set a priority. Priority in this context defines the sequence in which rules will be executed, lowest number to highest. To make this business rule active, check the Enabled checkbox.
Select a column name in the Select Criteria menu. Select a condition in the Conditions menu. Enter a value in the value field or select it from a list, if applicable. Click the Add button to add it to the list of criteria. This is most important, otherwise the criterion will not be saved.
When saved, the criterion will appear in a list. Note that multiple criteria can be defined in the one Business Rule. Also note the two options Match All (AND) and Match Any (OR), which will define whether all the specified criteria or any of them will be tested.
Similarly, select an action from the Select Action menu and enter a value in the value field or select it from a list, if applicable. Click the Add button to add it to the list of criteria. Again, this must be done to save the action. Multiple actions can be defined in the same Business Rule.
Click the Save button to save the Business Rule.