Page History

This section focuses on how incidents as are processed by agents. The following diagram shows the incident state model.

Tip
Role required: incident_manager.

Anchor

	state model
	state model

Image Removed

Image Added

Note
Infrastructure incidents cannot have the Rejected by User stateuser and Information needed states.

State Flow and Waiting states

The states of incident processing can be divided into:

Incident ProcessingState Flow. When an incident is in the a State Flow state, such as In Progressprogress, SLA indicators count down the time related to the incident processing until the SLA is breached.
Incident ProcessingWaiting. When an incident is moved to the a Waiting state, such as Information Needed Information needed, all SLA indicators related to the incident stop the countdown.

State Flow

The State Flow group includes the following procedures and states.

Procedure	State	Description	Available Transitions
Logging	Registered	The incident is recorded (via phone/email/Self-Service Portal) but not yet categorized.	Assigned In Progressprogress
Categorization	Assigned	The incident is categorized and assigned to a relevant person or a group.	In Progressprogress Information Neededneeded Completed
Diagnosis and Resolution	In Progressprogress	Someone An agent started working on the issue.	Assigned Postponed Information Neededneeded External Processingprocessing Completed
Closure	Completed	An incident is resolved when the agent provides temporary workarounds or permanent solutions. The agent changes the state to Completed ,so that the caller could assess the results. The caller receives a notification asking to evaluate the agent's job and the service level. If the user is satisfied with the solution, the incident is marked as Closed; otherwise, it is Rejected by Useruser.	Assigned In Progressprogress Rejected by Useruser Closed
Closure	Closed	The Agent Satisfactionsatisfaction and Service Satisfactionsatisfaction fields are present on the form to evaluate the agent performance. Both fields have the following values: Below Expectations Meets Expectations Above Expectations Image Removed On the Self-Service Portal, the caller can assess the results. The values of these evaluations are connected with the values of the choice options: Below Expectations = Disappointed Meets Expectations = Satisfied Above Expectations = Very Pleased Image Removed For more information, see General Concepts and Procedures. If an incident is not If the incident has not been closed after it was marked as Completed, it will be closed automatically over an adjustable time frame as set in system properties.

Info
Only the incident caller has the right to close the incident. However, in SimpleOne, this rule does not affect infrastructure incidents. The incidents of this type can be closed only by the responsible person agent after examination.

Waiting

The Waiting group includes the following procedures and states.

Procedure	State	Description	Available Transitions
Investigation Diagnosis and diagnosisResolution	Information Needed	If the issue description is not clear enough, the agent can request additional information by changing the incident state to Information Needed. Once the information is received, the agent should change the state to the previous one.	Assigned In Progressprogress Postponed External Processingprocessing
Diagnosis and Resolution	Postponed	The incident can be marked Postponed if resolving the resolving incident should be postponed for a known period. If the incident moves to this state, the agent should specify the resolving date in the date in the Resumption of work field. But if the incident affects business functions, it should have at least a temporary workaround.	In ProgressAssigned Information Neededneeded External Processingprocessing
Functional escalation	External Processing	If resolving the incident solving requires to involve involving a third party, then, after the reassignment, the incident state should be changed to External Processing. After the third party involvement is over, the agent should change the incident state and the assigned user to the previous ones.	In Progressprogress Postponed Information Neededneeded Completed
Resolution	Rejected by User	If the caller is not satisfied with the agent's work on the incident, they can change the state to Rejected by User to further address the defects.	Assigned In Progressprogress Completed

Incidents prioritization

The incident priority can be figured out based on the incident impact and urgency using the priority matrix.

The impact of an incident indicates the damage that may be caused to the business user. In SimpleOne, the impact can be categorized as:

Low
Medium
High
Very High

The urgency of an incident is based on the time remaining until the incident impacts on the business. In SimpleOne, the urgency can be categorized as:

Low
Medium
High
Very High

Based on the priority, incidents can be categorized as:

Low
Moderate
High
Critical

Anchormatrixmatrix Excerpt Include

SAPI:Priority ManagementSAPI:Priority Managementnopaneltrue

Assign and update incidents

Once the incident is registered, it should be assigned to a responsible person or group for further processing. To assign an incident, complete the following steps:

Navigate to Incident Management → All Incidents and open the incident you want to work onassign.
Find Select a user to assign the incident to in the Assignment Useruser field, click by clicking the magnifier icon to select a user to assign the incident to.(Optional) Complete the same step for the Assigned Group field.
(optional) Complete the same step for the Assigned group field.

There is also a quick way to assign an incident to a current user. To do so, click the Start work button in the right top corner to become the Assigned user. The incident state changes to In progress automatically. The assigned group field remains unchanged (either with a group specified or empty). This button is available for all users who are not assigned to the service request and who have the itsm_agent role, or belong to the assigned group.

To make any updates to the incident, complete the following steps:

Open the incident you want to an incident to work on.
Change the desirable necessary fields.
Click Save or Save and Exit exit to apply the changes.

Your changes will be displayed in the Activity Feed, in history. The following information is displayed:

Who initiated the update
Updated field
New field value
Previous field value

Activity view

Escalation rules

There are two possible types of escalation:

Functional. When the 1^st level service agents cannot solve an incident for some reason (lack of authority or competence), they escalate it to the 2^nd level service agents.
Hierarchical. This escalation is typically required when an incident is of a serious nature, or a set of incidents may take a lot of time. An issue can be escalated up to the management.

Closure information

Based on the SimpleOne SimpleOne state model, when an incident is resolved, it should be marked as Completed, which denotes the incident closure. Also, the agent should provide the following details:

Closure Codecode
Closure Notesnotes

Closure

Notes

code

In the Closure Notes field, add information on the work performed and other information related to this incident.

Closure Code

This code specifies an option for the closure.

Option	Description
Solved 1^st level	Service agents of the 1^st level solved the incident without functional escalation.
Solved 2^nd level	Service agents of the 2^nd level solved the incident (service agents of the 1^st level were unable to solve it).
Not Solved (Refused)	Agents could not reproduce the incident and did not find any disfunction.
Not Solved (Dropped)	This closure code is chosen when When the request is not an incident , but, for example, a change request.
Not Solved (No User Reaction)	This closure code is chosen when the When a user did not provide additional information during the Information Neededneeded phase.
Not Solved (Other)	This closure code is for For all other reasons.
Not Solved (Workaround)	This closure code means that the The incident has no permanent solution, but has a temporary workaround related to a known error.

Closure notes

In the Closure notes field, add information on the work performed, and other information related to this incident.

Process infrastructure incidents

Since infrastructure incidents are created without the involvement of a business user, their state model is different from other incidents. Infrastructure incidents do not have the Information needed and Rejected by user states. When such incidents are closed, it is not required to fill in the Agent satisfaction and Service satisfaction fields.