Configuring incident rules

By using Incident rules, you can change how the Incident Management component behaves responds when you work with it. For example, you can select if certain dates on the Incident form can be changed, or you can choose to make the Service CI field mandatory. The ability make these changes allows you to make the Incident Management component conform to your organization's business rules and workflow.

Unlike the Incident Management Settings, which apply globally, incident rules apply to specific companies. For example, you can create incident rules that determine how incident requests are assigned through the Assignment Engine on a company-by-company basis.

These incident rules are applied only to the user interfaces like mid-tier and Remedy with Smart IT and not to the API forms.

To configuring incident rules

You configure the Incident rules from the Incident rules form, as described in the following procedure.

1. From the Application Administration Console, click the Custom Configuration tab.

2. From the Application Settings list, choose Incident Management > Advanced Options > Rules, and then click Open.

   The Incident Rules form

   
   

    

3. Select the company to which this rule applies.
   If the rule applies to all companies, select Global.
4. Select if certain dates can be changed on the Incident form.
   The Changeable Reported Date, Changeable Responded Date, and Changeable Resolution Date fields indicate whether these dates on the Incident form can be modified after the incident has been resolved or closed. Only users with Incident Master permission can modify these dates.
   You can modify the Changeable Resolution Date field in the Classic View only.
5. In the Create Request On Submit field, select whether to create a request on submission of an incident. 
   If the Create Request On Submit option is set to Yes, when a user submits an Incident form, a corresponding request is created. The customer can view this request, which indicates the incident status, through the Requester console.
   The Requester console uses the requester's Remedy ITSM login ID to determine who created the request and where to display it. To see requests in the Requester console, therefore, the requester must have a Remedy ITSM login ID
6. In the Description field, you can enter a descriptive note about the rule.

7. Select whether the Service CI field is a required field.
   By default, the Service CI field is not a required field when an incident request record is created. This configuration is controlled by the Require Service CI Related On Submit flag. Out-of-the-box, it is set to No, which means that the Service CI field is not required when someone creates an incident request record. If your organization's business rules require a Service CI to be associated with an incident request, then select Yes.

   Important

   If you create an incident by using the HPD:IncidentInterface_Create web service and set the Require Service CI Related On Submit flag as Yes to indicate Service CI as a required field, the incident is created without any errors even when you do not enter any value in the Service CI field.

8. Select whether the CI field is a required field.
   You can configure the CI field to be a required field when someone changes an incident request record's status to Resolved. 
   This configuration is controlled by the Require CI Related On Resolved flag. Out-of-the-box, the it is set to No, which means that the CI field is not a required field. If your organization's business rules require a CI to be associated with an incident request when it is resolved (or before it is closed), then select Yes.
9. To configure the number of days after which an incident request automatically moves to the Closed status, type the number of days in the Auto Close Resolved (in Days) field.
   The number of days is calculated from the Last Resolved Date of the incident request record. The escalation runs daily at 2:00 A.M.
10. To use the Assignment Engine to automatically assign incidents to individuals, perform the following steps:
    1. Set Assignment Engine Integration to Yes.

    2. Select the appropriate Assignment Process.
       The following table describes the available assignment processes:

       Assignment Process	Description
       Capacity	The capacity for each person is specified in the Capacity Rating field on the People form. The capacity assignment process is a ratio-based method. For example, if person A has a capacity of 100 and person B has a capacity of 200, person B can handle twice as many tickets as person A. The assignment engine assigns two tickets to B, and then assigns one ticket to A.
       Number	The People form tracks the number of tickets assigned to the person. The number assignment process selects the person with the least number of tickets already assigned.
       Round Robin	The People form keeps track of the last time the person received an assignment. The round robin assignment process selects the person who was least recently assigned an incident.

       For information about configuring the assignment engine, see Configuring the Assignment Engine.

11. To configure how Incident Management responds when you try to resolve an incident request that has open tasks, choose one of the following selections:

    Message	Allowed?	Description
    Error Message (This is the default selection)	No	An error message indicates that the user must close all open tasks before resolving the incident. The user cannot resolve the incident until all tasks are closed, because the error stops all workflow processing.
    No Action (If the company is - Global -, this is the default selection)	Yes	No error message appears and the user can resolve the incident even if an open task is associated with it. The task, however, remains open.
    Warning Message	Yes	A warning message tells the user that the incident still has an open task associated with it. The user can still resolve the incident. The task, however, remains open. If a user cancels an incident, all of the associated tasks are also canceled.

12.  Select whether you want Incident Management to automatically create impacted area information based on the selected customer's location. The default selection is No. 
13. Click Save.
    For information about configuring CI-based routing in the Infrastructure Event Incident Rules area of the Incident rules form, click here.

To update incident rules

To change any of the Incident rules, open the Incident rules form as described in Configuring Incident rules, find the rule on the form that you need to change and make the required update. 

Infrastructure Event Incident rules

Use the Infrastructure Event Incident rules area of the Incident rules form to configure how Incident Management behaves when it is integrated with BMC Service Resolution. From this area of the Incident rules form, you can configure Incident Management to:

• Enable CI based routing (BMC Service Resolution 3.5 online documentation)
• Create a service request for every incident from BMC TrueSight Operations Management / BMC ProactiveNet (BMC Service Resolution 3.5 online documentation)
• Consolidate multiple, related events for the same CI into one incident instead of creating several incidents (BMC Service Resolution 3.5 online documentation)
• Consolidate incidents to avoid creating redundant incidents in your system (BMC Service Resolution 3.5 online documentation)
• Govern the status of incidents created by BMC TrueSight Operations Management / BMC ProactiveNet (BMC Service Resolution 3.5 online documentation)
• Allow incident routing by managed groups (BMC Service Resolution 3.0 online documentation)

For information about integrating the Incident Management component and BMC Service Resolution, see:

• Incident-Management-integrations
• Integrating-directly-with-Incident-Management in the BMC Service Resolution 3.0 online documentation