Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

What is Incident Status?

The status of an Incident indicates the stage at which the Incident is in its life cycle. Analysts or Users with appropriate access can modify the status of an Incident. 

Incident Stages

The following diagram shows the various stages of an Incident:

Figure: Incident Management Status (Figure Changed)

The following section explains the status of an Incident:

  • New: The status New cannot be selected by the users, it is assigned by the application after an Incident is logged.
  • Assigned: After the Incident is logged, it is assigned to a Workgroup, based on the selected Tenant. The Workgroup then specifies the Category, Classification, Urgency, Impact, Priority, Workgroup, and SLA Service Window based on the Symptom provided by the End User. The status of the Incident changes to Assigned.
  • In Progress: When the Incident is assigned to an Analyst, the status of the Incident is changed to In Progress. The Analyst can refer to various Knowledge Articles or Similar Incidents to work on the Incident.
  • Pending: If the Analyst cannot continue working on the Incident as the End User needs to provide some details or the Incident is dependent on any other activity to complete, the status of the Incident is moved to Pending.
  • Resolved: After the Incident is In Progress, the Analyst should resolve the Incident within the provided Service Window. After an Incident is resolved, the status of the Incident is changed to Resolved. Resolved incidents can be added as a Knowledge Base by selecting, Add to KB check box option on the Incident Details page. For more information about adding knowledge base record see, Adding Knowledge Records in Service Management. The End User can reopen the Incident if the resolution is not satisfactory.
  • Pending Approval: After an Incident is resolved, the status of the Incident is changed to Pending Approval. 

    Note:

    • If the Approver is not configured or inactive during workflow generation then the specific approval level will be skipped.
      For Example: Reporting Manager is selected as Approval Type, but the reporting manager for the caller of ticket is not configured or reporting manger is inactive then that approval level will be skipped.

    • Approval process will be triggered only if the Incident is resolved from the Incident Detail or Bulk Update functionalities. If the incident is resolved via API or e-mail to ticket/business rule then the approval process will not be applicable.

    Post Approval the incident can be Closed or Reopened.  If the incident is reopened incident status will be changed to In Progress and if the incident is closed then the incident status will be changed to Closed.

  • Closed: After an Incident is resolved, the status of the Incident can be changed to Closed based on the configuration (manual closure or auto closure).
  • Cancelled: The status of an Incident can be changed to Cancelled if the End User does not want any further investigation on the Incident (For reasons, such as the issue is resolved or unable to replicate the issue). This option is available to the users if configured by the Administrator.

Note:

The End User can provide Feedback for an Incident after it is Resolved/Closed (see: Viewing/Updating My Incidents).





  • No labels