- 25 Jan 2025
- 14 Minutes to read
- Print
- PDF
Manage Incidents
- Updated on 25 Jan 2025
- 14 Minutes to read
- Print
- PDF
Analysts can log issues, view and update recorded incidents, and perform all actions available to an End User.
Manage Incidents
To manage an Incident, perform the following steps:
Log in to the Apex Mobile.
The Analyst Dashboard is displayed.
Figure: Analyst DashboardClick Service Management and navigate to the Incident > Incident > Manage Incidents.
The Manage Incidents page is displayed.
Figure: Manage IncidentsClick New to create a new Incident.
Enter the required details as described in the following table and click Submit.
Field | Description |
---|---|
Symptom | A brief information on the Incident is provided. |
Description | Detailed information on the Incident with more explanation and clarity. |
Workgroup | Lists all the Workgroups corresponding to the selected Tenant. |
Analyst | Assign the incident to the appropriate Analyst. |
Service Window | Select the appropriate service window for calculating SLAs. For example; 24/7. |
Effort | Specify the Effort in Days, Hours, Minutes, & Seconds. |
Response SLA | The field displays the deadline within which a response acknowledgment must be received for the Incident. Notes:
|
Response SLA Violation remarks | The workgroup to which the Incident is assigned. Select the relevant remarks from the dropdown. For example: Working on other Incidents, Complex Issue etc. |
Resolution SLA | The field displays the deadline within which a resolution must be received for the Incident. Note: This field can be edited based on the configurations done in SLA. |
Resolution SLA Violation remarks | Select the relevant remarks from the dropdown. For example, working on other Incidents, complex issues, etc. |
The configuration is explained under each tab. Please expand the sections below for more details:
General
Field | Description |
---|---|
Requestor | The name of the requester who raised the incident is displayed. It is retrieved from the login username. |
Requestor Location | The location from which the requestor has raised the Incident is displayed. |
Tenant | A Tenant is similar to a department within an organization that provides support related to an IT or a facility. |
Service | Select a service required for the Incident. Options available are Emergency Response Service, MS Office 365, Navigation. |
Medium | Select the medium of Incident logging. Options available are: Web, Mail ,Chatbot, Mobile App, Others. |
Source | Select the origin of the Incident being logged. Options available are: User, Event, Incident, Change, Problem, Others. |
Classification | Select the appropriate option from the classification pop-up window which provides various categories. |
How would you categorize the issue? | Find and select the appropriate category to which the Incident belongs to from the category list. |
Tags | Add relevant Tags for better reach or provision to create new tags are also available. |
Major Incident | Click the toggle-button and mark as Major Incident only if the Incident is of High priority, High Impact and Urgency and needs faster resolution. |
Propose Major Incident | Enable the button if the Incident needs to be proposed as a Major Incident. When the incident is proposed as a Major Incident, it is transferred to the Approver for the approval process. |
Prioritization | |
Impact | Impact defines the enormity of the situation and the extent of consequence related to the incident. The options available are Critical, High, Low, and Medium. |
Urgency | This field represents the urgency-based factor for Incident. Options available are: Critical, High, Low, Medium. |
Priority | Priority defines the precedence in which a particular Incident should be addressed. The options available are P1, P2, P3, P4, and P5. |
Messages
Field | Description |
---|---|
User Communication | Type in the problem information that you want to share with the Requestor. Only the workgroup Analysts can update the User Communication. Also, the Analysts can use the preconfigured templates to update the User Communication. |
Private Log | Type in the problem information that you want to share with other members of your Workgroup. Apart from workgroup Analysts, the Private Log can be updated by Authorizers, Approvers, and Reviewers. |
Messages | Any other messages related to the Incident can be added in the message section. |
Notes for Self | This is self note section for individual reference. |
Checklist
Field | Description |
---|---|
Checked Windows updates and suggested any critical updates and impact? | Maintaining a secure, stable, and up-to-date operating system with the newest features and enhancements requires regular Windows updates. Select Yes or No from the dropdown menu. |
Backed up DFS Namespace Configuration | Distributed File System (DFS) Windows Server namespace is a feature that lets you combine shared folders from various servers into a single namespace. Select Yes or No from the dropdown menu. |
Are Antivirus Logs checked & updated? | Records produced by antivirus software that detail actions taken in connection with identifying and addressing possible security risks on a system or network are known as antivirus logs. Select Yes or No from the dropdown menu. |
Solution
Field | Description |
---|---|
I found this solution in a knowledge article. | Enable this if you could find the resolution to your Incident in a knowledge article of documentation. Majority of times there are possibilities a resolution can be found from existing knowledge article. |
Please link the article that helped | Select from the dropdown list which is the article that helped you resolve the Incident all by yourself.
|
Troubleshooting
Field | Description |
---|---|
Problem | Enter the Problem of the Incident for reference. |
Cause | Enter the cause of the Incident. |
Proposed Solution | Suggest a possible solution which can resolve your Incident. |
List | This is a cumulative list which gets added with multiple Problem, Cause and Proposed Solutions |
Link
The Incident record can be linked to other records from the same module, another module, or an application by using the Links tab. From the Incident details page, users have the option to create new records or link to already-existing ones.
Link the existing Manage pages from the dropdown list provided in the Links section. This view will provide a list of all the records that have been linked to the record.
Analysts can perform the following actions through the Links tab:
Create
Link
De-link
Create
This feature allows a new record to be created from an incident. A new record gets created with fields auto-populated.
The link tab contains the relationship record with the create button. The create button can be triggered to create a new record from an incident. For example Incident to Service Request.
Note
The form will open in a new tab and all the fields will be auto populated based on the form relationship selected.
Link
Link contains a feature to Link other records to the Incident. This feature is useful to create an association between related records.
The Link tab allows linking an incident with other modules in the application. For example, linking an incident to a service request or linking an incident to a problem record. There is also a provision to link records across application. For example, linking service request to fixed asset.
Note
The link tab can be used to display and link Instore Assets and User Assets
In-Store Assets: This will display the list of records in store.
User Assets: This will display the list of assets allocated to the specific user.
Select a module and the following page is displayed.
Note
Select the records to be linked and click Link. Records from the same module can be linked as Parent-Child and other modules can be linked as Peer.
Peer Records are related or similar records to the incident being investigated. An incident cannot be resolved without closing the linked peer records.
For example, if a work order or service request has been raised for an incident, it cannot be resolved till the work order/service request has been closed. The following validation message is displayed when the incident is closed.
The Parent-Child dependency can be selected if the incidents are related to the same main incident. Any updates on the parent incident will also reflect on the child incidents.
Child records are not editable once linked. The linked child record will display the following message when opened.
Any changes to the parent records will reflect on the child records. There is a provision to exclude certain fields from being updated in the child record by defining exceptions in the Relationship configuration. Once configured, changes to the child incident can be limited by selecting the required fields as shown below. Only selected fields will be updated in the child incident.
All the linked records of different modules will be displayed as below.
Note
The condition builder has been introduced to display only open records while linking. For more information on configuration, refer to the Relationship feature in Form Designer.
De-Link
Removing the connection or linkage between two records that are tied to an incident is known as de-linking the records. This step may be required if a record is incorrectly linked, no longer relevant, or if the process changes and the linked records need to be disconnected.
To de-link record(s) from an SR, perform the following steps:
Click Link tab.
All the records which are link to the Incident are displayed.Select the check boxes of the records which you want to de-link.
Once you select the records that you want to de-link, the De-Link button is enabled.Click De-Link.
A message stating successful de-linking is displayed.
Vendor Info
Field | Description |
---|---|
Vendor Name | Select the Vendor from the dropdown list. Example: Cisco, Apple. |
Location | Select the Location from the dropdown list. Example: India, Austria. |
Configuration Items | Select the appropriate CI (Configuration Items) from the list. |
Services | Select the Services relevant to the Vendor from the dropdown list. |
Contact Person | Select the contact person for the vendor from the dropdown list. |
Incident ID | Enter an Incident ID of the Parent Incident if exists. |
Status-Vendor | Add relevant tags for better reach or provision to create new tags are also available. |
Vendor-Urgency | Justification or Valid reason for keeping the Incident in Pending status. For Example, dependency on another team, No proper information available. |
Start Date | Select a start date as per requirement. |
Vendor Impact | To mark as Major Incident only if the Incident is of High priority, High Impact and Urgency and needs faster resolution. |
Resolution Deadline | Impact defines the enormity of the situation and mostly deals with “How Many” question. |
Vendor-Priority | Time based factor for Incident. Options available are: Critical, High, Low, Medium. |
End Date | Select the end date as per requirement. |
Underpinning Contact | The Underpinning Contract (UC) is a contract between an IT service provider and a third party. The third-party provides support services that enable the service provider to deliver a service to a customer. |
Solution | Propose a possible solution for the Incident. |
Timeline
Timeline displays the chronological events and timestamp of tasks and progress on the Incident. Refer to the screenshot below for more information.
Orchestration
Repetitive tasks must be executed to resolve an incident automatically or with less manual intervention. Based on the configured scripts, the action is executed automatically.
Edit Manage Incidents
To edit an Incidents, perform the following steps:
Navigate to the Service Management > Incident > Incident > Manage Incidents.
The Manage Incidents page is displayed.
Figure: Manage IncidentsClick Incident ID hyperlink to view the Incident detail.
Edit the required details and click Save.
From the application banner has few action icons which are explained in the table below.
Change History
Change History is a detailed chronological record of all modifications made to a specific item, process, or system during its lifecycle. To view the complete record or log of all the changes made to the Incident throughout its lifecycle by click Change History icon.
Figure: Change History
Click the "Change History" ribbon to expand and view the full details of changes made to the Incident. It shows the date and time of each change, along with information such as Impact, Urgency, Priority, Pending Reason, Requestor, Tenant, Classification, Status, Workgroup, Service Window, and more.
Communication History
A communication history is a list or documentation of all the exchanges of messages, discussions, and interactions that have taken place over a given time period between different people or entities. It offers an in-depth description of who spoke with whom, when, and what was said.
Figure: Communication History
Click Log to find the audit trail of communication.
Workflow History
View the entire history and progress of the Workflow. Workflow History refers to a log or record of actions and events that have taken place during a workflow or business process. Workflows are a popular tool for managing and streamlining intricate procedures, guaranteeing that assignments are finished quickly and methodically.
Click the highlighted icon and the following page is displayed with the workflow diagram.
Note
The green line denotes approvals done and the orange box denotes the status at which the approval is pending.
Link History
Link history usually means a list of URLs or hyperlinks that are pertinent to the incident. This can be significant in a scenario where a particular incident is linked to another record.
Figure: Link History
Note
The link history is also used to track changes in the event of conversion of records. For example, when a service request is created from an incident or vice versa, or Incident to Service Request, Incident to Work order, etc.
SLA History
The term "SLA history" describes the progression and historical development of service-level agreements. It includes the main turning points, how SLAs have changed over time, and how businesses have utilized them to monitor and guarantee the caliber of services they offer to clients.
Figure: SLA History
Resolution SLA - Resolution SLA refers to a service provider's guarantee as to how quickly they will address and fix a reported issue or request.
Response SLA - Response SLA is the guarantee given by a service provider on how quickly they will react to a customer's request or issue that they have reported.
Click and view the SLA History in Timeline View or Tabular View. The Rule History provides a log of any rule changes adopted during the progress of the Incident. Any such changes will be reflected in the SLA value being calculated for completion of the Incident.
SLA Detail History - The Detail History will have a comprehensive log of the SLA details captured to provide a birds-eye view of the status of SLA and elapsed time.
SLA Deadline History - A historical tracking of compliance with deadlines providing a history of how deadlines or timelines have been managed in the context of SLA.
Business Rule History
View the list of Business rules triggered and satisfied for the Incident. It also provides a log of the business rules triggered with details.
Figure: BR History
Click on the highlighted part to reveal the business rules that were satisfied and triggered and vice versa.
Business Rules Satisfied - This provides the details of the business rules that were triggered and satisfied.
Business Rules Not satisfied - This provides details of the business rules that were triggered and not satisfied.
Search Function is available for BR history logs using Keywords
Note
Whenever an action fails during the processing of a business rule, resulting in a 'Failed' status, the Business Rule History will display the status as 'Failed' along with reason for the failure, accompanied by the error. This is crucial for facilitating the investigation of the issue.
Access History
It provides details of the access details and history of accesses in chronologically descending order.
Figure: Access History
More Options
Click (More Options) to view more options available to the Analyst. The following options are available in this section. Each section has been explained in detail below. Let us see each of the above in detail.
Reminder
Reminders are used in an incident management as a proactive measure to guarantee that events are handled effectively, in accordance with SLAs, and with an emphasis on ongoing improvement.
Click the Reminder and the following page is displayed.
Figure: Reminder
Set Reminders for specific date and time and enable Notify Me to receive Notifications.
Also, you have an option to Create Incident for reminder too.
Remote Desktop
Remote desktop functionality is a valuable tool in incident management, where you make take control of the End user's system to analyze the issue. It is useful when it comes to troubleshooting and resolving IT issues.
Click Remote Desktop and the following page is displayed.
Figure: Remote Desktop
Set Remote Desktop connections for specific RDP Type and add Analyst E-mail ID to send Notifications.
Also, the Requestor E-mail ID is selected by default, and you can change the same.
AI Suggestions
Artificial intelligence (AI) has the potential to significantly improve incident management procedures by providing insightful recommendations and modifications that increase productivity, accuracy, and issue-solving efficacy. AI-driven recommendations can help make incident management more proactive, effective, and responsive, which will ultimately enhance the delivery of IT services as a whole.
To use AI Suggestions, perform the following steps:
Click icon and click AI Suggestions.
The AI Suggestions page is displayed.
Figure: AI SuggestionsConfigure the required details and click Apply.
Based on the inputs such as Symptom and Description, Service Desk Intelligence scans all the available history or records and identifies similar records. Further, the Service Desk Intelligence understands human responses to similar records in the past and then provides suggestions. Analysts can view and apply the AI suggestions by clicking Apply. However, the predictions made by Service Desk Intelligence is a reflection of past data. If sufficient records exist with “proper” data, the field predictions are in conjunction with that.
The Service Desk Intelligence makes the Analyst's job easier by auto filling the following fields of the Incident based on the Service Desk Intelligence: Workgroup, Impact, Urgency, Category, Classification. By default, these fields are enabled. Click Cancel if you do not want to apply the AI suggestions to the record's details page.
Transfer Incidents
The process of transferring responsibility for handling an incident from one support group or team to another. This transfer might occur for various reasons, such as when the initial team realizes that the incident requires expertise or resources beyond their scope, or when there's a predefined escalation or handover process in place.
Click Transfer Incidents and the following page is displayed. Transfer the Incidents to appropriate Tenant, Workgroup with Remarks on why is the Incident being transferred.
Article Suggestions
Article Suggestions provide articles of similar interest that can be referenced for resolution of the incident. This can help in knowledge sharing and problem solving. This knowledge sharing mechanism can enhance the efficiency and effectiveness of incident resolution process.
Click Article Suggestions and the following window is displayed.
Figure: Article Suggestions
Generate Insights
The Incident Management "Generate Summary" function streamlines the process of producing thorough incident summaries, guaranteeing that all relevant parties have a clear understanding of the incident details, resolution procedures, and any necessary follow-up actions.
Figure: Generate Insights
Click the icon to generate a summary of the Incident. The Create Template icon can be used to create a new template from existing incident details. Click the Create Template icon and the following page is displayed. Provide a Template name with sufficient Tags for the template. Enable the toggle button to make the template available for the end user.