Searching the Help
To search for information in the Help, type a word or phrase in the Search box. When you enter a group of words, OR is inferred. You can use Boolean operators to refine your search.
Results returned are case insensitive. However, results ranking takes case into account and assigns higher scores to case matches. Therefore, a search for "cats" followed by a search for "Cats" would return the same number of Help topics, but the order in which the topics are listed would be different.
Words and Phrases
| Search for | Example | Results |
|---|---|---|
| A single word | cat
|
Topics that contain the word "cat". You will also find its grammatical variations, such as "cats". |
|
A phrase. You can specify that the search results contain a specific phrase. |
"cat food" (quotation marks) |
Topics that contain the literal phrase "cat food" and all its grammatical variations. Without the quotation marks, the query is equivalent to specifying an OR operator, which finds topics with one of the individual words instead of the phrase. |
Using Boolean Operators
| Search for | Operator | Example |
|---|---|---|
|
Two or more words in the same topic |
|
|
| Either word in a topic |
|
|
| Topics that do not contain a specific word or phrase |
|
|
| Topics that contain one string and do not contain another | ^ (caret) |
cat ^ mouse
|
| A combination of search types | ( ) parentheses |
|
Incident Management form details
The following table identifies and describes some of the features on the Incident Management forms.
Note When setting up events or web services to create incidents automatically, you must be sure to include all required fields for the incident.
|
Label |
Description |
|---|---|
|
Incident ID |
The system-generated unique ID for this incident. |
| Title |
A short description that summarizes the incident. This field is prepopulated with data from an escalated interaction. This is a required field. |
| Description |
A detailed description of the incident. This field is prepopulated with data from an escalated interaction. This is a required field. |
| Phase |
This is a system-generated field. These phases are available out-of-box:
|
|
Status |
Displays the status of the incident. These statuses are available out-of-box:
|
| Affected Service |
The service affected by this incident. This field is populated with data from the interaction record. See Service Desk Interaction Management form details for additional information. This is a required field. |
| Affected CI |
The configuration item (CI) that is affecting the service negatively. This field is populated with data from the interaction record. See Service Desk Interaction Management form details for additional information. This field includes a hover-over form that displays Critical CI and Pending Change check boxes to indicate whether or not these attributes apply to the CI. |
| CI is operational (no outage) | This field indicates that the item is currently operational and that there is no outage if selected (set to true). By default when you open an incident against a CI, the CI is flagged as down. If the CI is still working, you should mark this field. |
| Outage Start | The date and time when the outage started. The outage start and outage end times are used to measure the availability for the Service Level Agreements (SLAs). If the CI is flagged as down, availability SLAs start counting against the CI. The default availability value is the incident open and close times, but you should change this value to report the actual outage start and end times because it may be several minutes or hours before the incident is opened or closed. For example, the device may have gone down in the night and the incident is not opened until someone reports the problem. In this case, the default open time does not accurately reflect the outage time. |
| Outage End | The date and time when the outage ended. The outage start and outage end times are used to measure the availability for the SLAs. If the CI is flagged as down, availability SLAs start counting against the CI. The default availability value is the incident open and close times, but you should change this value to report the actual outage start and end times because it may be several minutes or hours before the incident is opened or closed. For example, the device may have gone down in the night and the incident is not opened until someone reports the problem. In this case, the default open time does not accurately reflect the outage time. |
| Category |
This field describes the type of incident, based on ITIL service-centric processes. This field is prepopulated with data from the escalated interaction. This is a required field. A workflow is bound to a category. You must select a category before opening an incident form if the incident is not opened from an interaction and there is no default category specified. If required, the Incident Coordinator, Incident Manager, and Incident Analyst can update this field and the related subcategory and area fields for incidents assigned to them. This field is read-only, to update the category, they need to click More > Change Category menu option. The following categories are available for the out-of-box incidents:
|
| Subcategory |
This field is prepopulated with the data from the interaction from which the incident is opened. The subcategory selections depend on the category. This is a required field when phase starts from Categorization. The out-of-box data is the same as in Interaction Management, but can be different. For additional information, see Service Desk Interaction Management form details and Interaction categories. |
| Area |
The third level of classifying an interaction, mainly used for reporting purposes. This field is prepopulated with the data from the interaction from which the incident is opened. Service Manager displays different lists of areas, depending on the subcategory selected. For more information on categories and the areas and subareas associated with them, see Interaction categories. The out-of-box data is the same as in Interaction Management, but can be different. For additional information, see Service Desk Interaction Management form details. |
| Impact |
This field is prepopulated with data from an escalated interaction. It specifies the impact the incident has on the business. The impact and the urgency are used to calculate the priority. These impacts are available out-of-box:
|
| Urgency | This field is prepopulated with data from an escalated interaction. The urgency indicates how pressing the incident is for the organization. The urgency and the impact are used to calculate the priority. For additional information, seeService Desk Interaction Management form details. |
| Priority | The order in which to address this incident in comparison to others. The priority value is calculated using initial impact and urgency. This field only appears for incidents being updated or escalated from interactions. |
| Major Incident | If selected (set to true), this field indicates that the issue is a major issue, which requires informing the specified Incident Manager, and imputing review details under the Major Incident Review section. |
| Escalated | If selected (set to true), this field indicates that the incident needs to be escalated to Incident Manager, and possibly additional escalation teams also need to be aware of. |
| Requested By | The name of operator who opened the Incident ticket. This field is populated with the current operator. |
|
Contact Person |
This field contains the contact name related to the company for this incident. This field ensures that the correct person will be notified about updates to the incident. This field is prepopulated with data from an interaction when a user opens an incident from an interaction. |
| Location |
The location for which the incident has been reported. This field is for informational purposes only. Location data is customer and implementation specific. |
| Source |
The source from which the record is created. The following out-of-box sources are available:
|
| Parent Incident |
If selected (set to true), this field indicates that the incident is a parent incident, that allows other incidents link to it for issue classification, and the child incidents can be viewed under Child Incidents section. If unselected later after being selected, all the linked child incidents are unlinked. Once an incident is set as a parent incident, it cannot be linked to a parent incident any longer. |
| Link to Parent Incident | The ID of the parent incident. This field can be populated with incident ID based on predefined query for parent incidents. One incident can only be linked to one parent incident. Once linked to a parent incident, this incident cannot be set as parent incident any longer. |
|
Categorization and Assignment section > Assignment Group |
The support group assigned to work on this incident. The affected service or CI specified in the interaction form determines which default assignment group the system assigns to incidents that were escalated from interactions. An administrator assigns the default assignment group for a service on the Configuration Item (CI) detail form for the CI. When you search for the service in Configuration Management (Configuration Management > Resources > Search CIs), you see the default assignment group for the service or CI specified in the Config admin group field. When you escalate an interaction to an incident, the assignment group is prepopulated, based on the CI or service (if no CI selected, then based on selected service) selected in the interaction. You can change the assignment group, if necessary. The out-of-box data consists of default assignment groups for use as examples of types of assignment groups. Tip You may want to adapt the sample assignment groups to meet your own needs. These assignment groups are available out-of-box:
This is a required field. |
|
Categorization and Assignment section > Assignee |
The name of the person assigned to work on this incident. This person is a member of the assigned support group. Assignees may belong to one or multiple assignment groups, based on the needs of your company. |
| Categorization and Assignment section > Expected Resolution Time | The Incident Coordinator can use this field to set an expectation for incident resolution time. |
| Workflow section | Workflow section displays a figure of incident workflow. It also indicates the current phase which the incident is in, and traces the phase transition history. |
| Tasks section |
The user can add tasks whenever an incident is in a phase. Every task has to be finished before close the incident. To add a new task, click the Tasks section, and then click the Link New Task button. Service Manager provides a quick view of some of the most important fields in the task in the Tasks section. The data displayed includes the following information:
|
| Cost section | The user can add cost details of parts and labor for incident handling. For parts cost, the user needs to add expense lines with the part number from product catalog and the quantity that have been used during the incident handling. For labor cost, the user needs to add technicians who have been working on the incident with the working hours. Select a currency for cost calculation, then the total cost of the incident will be calculated by the system. |
|
Activities > Vendor/Supplier |
The name of the vendor/supplier the incident is assigned to. Used when a vendor/supplier needs to be involved in fixing the incident. |
|
Activities > Vendor/Supplier Record |
This number refers to the incident number from the vendor/supplier logging system. This is an informational field for reference only. This field is only visible when incident status is Pending Vendor/Supplier. |
|
Related Records section > Link Type |
Specify a relation type between problem and target ticket. These link type groups are available out-of-box:
|
|
Related Records section > Link Existing/New Record button |
After select a link type, uses these two buttons to associate the incident with target ticket, or create a new target ticket and associate with this incident. |
|
Related Records section > All Related Records table |
Information of all related records of this problem is displayed in this table. The data displayed includes the following information:
|
| Related Records section > Unlink Record button | If you want to disassociate the incident with another ticket, select the related ticket from All Related Records table, and click this button to unlink these two tickets. |
| Proposed Solution/Recovery Action section > Solution | Provides a description of the solution for the incident. |
|
Proposed Solution/Recovery Action section > Problem Candidate |
If selected (set to true), this field indicates that the issue that caused the incident is most likely a problem. When selected, either a problem should have been created, or the incident should have been associated with other problems. This field is only enabled for users who have Expert rights. This capability is specified on the Incident Management Security Role area. When the Problem Management Candidate field is checked for the incident, the incident appears in the Problem Manager default view for incidents. The Problem Manager can then review the incident to decide whether or not to open a related problem. Examples of problem candidates include cases where several customers report the same issue or where an issue recurs repeatedly. |
|
Closure Code |
Specifies a predefined closure code to describe how the incident has been resolved. The out-of-box options in this field are based on customer reference data. Tip You may want to tailor these options to match your business needs. These closure codes are available out-of-box:
|
| Completion Comments | This field is to document additional comments to close the incident. |
|
Affected Services |
This section provides a list of affected services for the incident. When a configuration item for the incident is added or updated, a schedule record is created that runs a routine to update the list of affected services. If the incident is locked, the routine reschedules the schedule record for 5 minutes later. |
|
SLT > |
This subsection provides a list of process SLTs related to the incident. The information includes Agreement name, status, SLT name, From and To specifications for the Agreement, and Expiration. Similar information is available for interactions, problems, and changes. |
|
SLT > |
This subsection displays uptime availability data for the SLTs related to the incident. The data displayed includes the following information:
Similar information is available for interactions, problems, and changes. |
|
SLT > |
This subsection displays duration availability data for the SLTs related to the incident. The data displayed includes the following information:
Similar information is available for interactions, problems, and changes. |
|
SLT > |
This subsection displays all upcoming Agreement alerts to help users prioritize the incidents needing attention. The data displayed includes the following information:
Note For additional information, see the online Help topic, Service Level Agreement alerts. |
