Layton ServiceDesk - General Settings - Business Rules
Contents |
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.
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.
- Awaiting User Response:
- 2 Days no Response (same settings).
- 4 Days no Response (same settings).
- Awaiting User Response:
- Create 3 Business Rules. Note that sys_changestatus_date must appear first in the list of criteria.
- Status Change 1
- Status Change 2: Change these settings:
- Rule Name: Status Change 2
- Description: If status is not changed within 32 hours, and status is "2 Days No Response", change to "4 Days No Response"
- Select Criteria:
- sys_changestatus_date after 32 Working Hours
- sys_requeststatus (Request Status) is 2 Days No Response"
- Perform these action: sys_requeststatus (Request Status) 4 Days No Response
- Status Change 3: Change these settings:
- Rule Name: Status Change 3
- Description: If status is not changed within 40 hours, and status is "4 Days No Response", change to "Closed"
- Select Criteria:
- sys_changestatus_date after 40 Working Hours
- sys_requeststatus (Request Status) is 4 Days no Response
- Perform these action: sys_requeststatus (Request Status) Closed
- Status Change 1
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.
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.
- Awaiting User Response:
- 2 Days no Response (same settings).
- 4 Days no Response (same settings).
- Awaiting User Response:
- Create 3 Business Rules. Note that sys_lastcommentdate must appear first in the list of criteria.
- Reset Status 1
- Reset Status 2: Change these settings:
- Rule Name: Reset Status 2
- Description: If End User comments within 32 hours, and status is "2 Days No Response", change to "Open"
- Select Criteria:
- sys_changestatus_date within 32 Working Hours
- sys_requeststatus (Request Status) is 2 Days No Response"
- Perform these action: sys_requeststatus (Request Status) Open
- Reset Status 3: Change these settings:
- Rule Name: Reset Status 3
- Description: If End User comments within 40 hours, and status is "4 Days No Response", change to "Closed"
- Select Criteria:
- sys_changestatus_date within 40 Working Hours
- sys_requeststatus (Request Status) is 4 Days no Response
- Perform these action: sys_requeststatus (Request Status) Closed
- Reset Status 1
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.
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.