Process Incidents

tip

Role required: incident_manager.

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

note

Infrastructure incidents cannot have the Rejected by user and Information needed states.

State Flow and Waiting states

The states of incident processing can be divided into:

• State Flow. When an incident is in a State Flow state, such as In progress, SLA indicators count down the time related to the incident processing until the SLA is breached.
• Waiting. When an incident is moved to a Waiting state, such as 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 progress
Categorization	Assigned	The incident is categorized and assigned to a relevant person or a group.	In progress Information needed Completed
Diagnosis and Resolution	In progress	An agent started working on the issue.	Assigned Postponed Information needed External processing Completed
Closure	Completed	An incident is resolved when the agent provides temporary workarounds or permanent solutions. The agent changes the state to Completed for the caller to assess the results. An incident is also automatically moved from the Information needed to the Completed state if the caller does not respond within the specified time frame. 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 user.	Assigned In progress Rejected by user Closed
Closure	Closed	If an incident is not closed after it was marked as Completed, it is closed automatically within an adjustable time frame.

note

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

Waiting

---

The Waiting group includes the following procedures and states.

Procedure	State	Description	Available Transitions
Diagnosis and Resolution	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. If the caller does not respond within the specified time frame, the incident is automatically moved to the Completed state.	Assigned In progress Postponed External processing
Diagnosis and Resolution	Postponed	The incident can be marked Postponed if resolving the incident has to be postponed for a certain period. If the incident moves to this state, the agent must specify the date they plan to resume the work on the incident in the Resumption of work field. However, if the incident affects business functions, they should at least provide a temporary workaround.	In progress Information needed External processing
Functional escalation	External processing	If resolving the incident requires involving a third party, 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 progress Postponed Information needed 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 progress Completed

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:

1. Navigate to Incident Management → All Incidents and open the incident you want to assign.
2. Select a user to assign the incident to in the Assigned user field, by clicking the magnifier icon .
3. (optional) Complete the same step for the Assignment group field.

Alternatively, simply click the Assign to me or Start work button to assign an incident to the current user. The buttons are available for all agents who are not currently assigned to the incident, but have the ITSM_agent role or are members of the group specified in the Assignment group field. You can also assign multiple incidents at once.

The Assign to me button moves the incident into the Assigned state, and the Start work button moves the incident into the In progress state.

Whereas the Assigned to field is completed with the name of the current user, the Assignment group field is completed depending on the following conditions:

• If the Primary group (primary_group) field on the current user's page is completed, then an empty Assignment group field on the incident form is completed with the primary group value.
• If the Primary group field on the current user's page is completed, but the Assignment group field on the incident form is filled with a different value, then the Assignment group is completed with the primary group value.
• If the Primary group field is empty, but the Assignment group is completed with a group to which the user belongs, then the Assignment group field keeps its value.
• If the Primary group field is empty, but the Assignment group is completed with a group to which the current user does not belong, then the Assignment group is cleared.

If the Assignment group field is updated when the Assigned user field is empty, then the system sends a notification to the members of the assigned group.

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

1. Open an incident to work on.
2. Change the necessary fields.
3. Click Save or Save and 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

note

For child incidents, some fields can only be edited by the users with the admin role. They are automatically filled in with the information from the parent incident.

Activity view

Assign multiple incidents

---

You can assign multiple incidents at once.

info

The maximum assignable number is specified in the itsm.mass_processing.max_number_to_assign property. If you exceed this limit, an error will be displayed, and the action will not be initiated.

To assign multiple incidents, follow these steps:

1. Navigate to Incident Management → All Incidents.

2. In the list, select the checkboxes next to the incidents you need to assign.

3. Click Assign in the upper-right corner of the page.

4. In the modal window that opens, select the Assignment group or Assigned user. You can search for them in the dictionary opened by clicking the magnifier icon .

   note

   You can assign incidents:

   • to both a group and a user belonging to this group.
   • to a group without specifying a user.
   • to a user without specifying a group. In this case, if the Assigned user has a primary group, it is automatically added to the Assignment group field. You can change this group manually if needed.

   

5. If needed, activate the Add comment toggle to leave comments in the Work note and Discussion fields that appear.

   note

   The Discussion field is not available for infrastructure incidents. This is because this field is intended for communicating with the portal users, while infrastructure incidents are created by agents or the monitoring system. To communicate with the agents working on the incidents, use the Work note field.

6. Click Assign to apply the changes.

After that, the values that you specified in the modal window are automatically added to the corresponding fields of the incident forms. The assigned incidents' state changes to Assigned.

Escalation rules

There are two possible types of escalation:

• Functional. When the 1st level service agents cannot solve an incident for some reason (lack of authority or competence), they escalate it to the 2nd 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.

Reclassify an incident as a service request

tip

Role required: itsm_agent or admin.

If an incident is not an infrastructure incident and its state is not Closed, you can reclassify it as a service request. For example, if the caller selected a wrong request type.

To reclassify an incident as a service request, follow these steps:

1. Navigate to Incident Management → All Incidents.

2. Open the incident you need to reclassify. Ensure that this incident is not an infrastructure incident and that its state is not Closed.

3. Click Service Request in the upper-right corner of the page.

4. In the modal window that opens, select the Service Request model and click Continue. You can continue without selecting the model if you need to create a non-typical request.

   

5. If you selected the service request model, this model's widget appears on the incident form. Fill in the required fields and click Create. This opens the created request. It is prefilled with the information from the incident in the fields listed below.

   

   Service request fields prefilled with information from the incident

   On the General tab:

   • Impact
   • Urgency
   • Assignment group
   • Assigned user
   • Subject
   • Description
   • Related CIs
   • Caller
   • Company
   • Service
   • Attention required
   • Followers list
   • Contact type

   On the Related Records tab:

   • Related articles
   • Solved by changes

6. If you did not select the service request model, clicking Continue in the modal window opens the service request creation form. It is prefilled with the information from the incident in the fields listed above. You can change this information if needed. Click Save or Save and exit to apply the changes.

The service request is created in the Registered state. It is marked as Created from Incident. It has all the attachments from the reclassified incident.

After you create the request, the state of the incident changes to Completed with Not solved (created by mistake) as its Closure code. The Closure notes field displays a comment about the creation of the request. If the incident was a child incident, it is detached from the parent.

The service request and the incident it was created from are linked to each other:

• On the service request form, the Related Incident field on the Related Records tab displays a reference to the incident.
• On the incident form, the Related Service Request field on the Related Records tab displays a reference to the service request.

The selected service request model is displayed in the Related request model field on the request form. You cannot change the selected model.

The caller is sent an email notification about the reclassification of the incident as a service request. The notification contains links to the portal views of both the incident and created service request.

note

Incidents can also be created from service requests. You can find these incidents in the Incident (itsm_incident) table by adding the Created from Service Request column to the list interface. This information is also displayed in an incident's History.

Complete incidents

Closure information

---

Based on the SimpleOne state model, when an incident is resolved, it should be marked as Completed, which denotes the incident closure. This causes the Closure information tab to appear on the incident form. The agent must provide the following details:

• Closure code
• Closure notes

Closure code

This code specifies an option for the closure.

Option	Description
Solved 1st level	Service agents of the 1st level solved the incident without functional escalation.
Solved 2nd level	Service agents of the 2nd level solved the incident (service agents of the 1st level were unable to solve it).
Not solved (Cannot be reproduced)	Agents could not reproduce the incident and did not find any disfunction.
Not solved (Created by mistake)	When the request is not an incident but, for example, a change request.
Not solved (No user response)	When a user did not provide additional information during the Information needed phase.
Not solved (Other)	For all other reasons.
Not solved (Workaround)	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.

You can add a quick response by clicking the Quick Responses widget icon , if the widget is added to the form. Read more in the Quick Responses article.

Complete multiple incidents

---

You can complete multiple incident tickets at once.

note

Mass completion from the list view is available for all incident types except for major incidents. You can only complete major incidents via their respective forms. Note that in addition to the Closure code and Closure notes, you need to specify a major incident's Chronology to complete it.

The maximum number of tickets that can be completed at once is specified in the itsm.mass_processing.max_number_to_complete property. If you exceed this limit, an error will be displayed, and the action will not be initiated.

To complete multiple incident tickets, follow these steps:

1. Navigate to Incident Management → All Incidents.

2. In the list, select the checkboxes next to the incident tickets you need to complete.

3. Click Complete in the upper-right corner of the page.

4. In the modal window that opens, specify the Closure code and fill in the Closure notes.

   

5. If needed, activate the Add comment toggle to leave comments in the Work note and Discussion fields that appear.

   note

   The Discussion field is not available for infrastructure incidents. This is because this field is intended for communicating with the portal users, while infrastructure incidents are created by agents or the monitoring system. To communicate with the agents working on the incidents, use the Work note field.

6. Click Complete to apply the changes.

After that, the values you specified in the modal window are automatically added to the corresponding fields of the incident forms. The incidents' state changes to Completed.

Complete incidents automatically

---

If an incident is in the Information needed state, and the caller does not respond within the specified time frame, the incident is automatically moved to the Completed state:

• Not solved (No user response) is selected as the Closure code.
• A comment about the lack of response from the caller is added to the Closure notes.

The caller is notified that the work on their ticket has been completed.

You can specify the number of days after which incidents with no caller response are automatically completed in the system property itsm.itsm_incident.days_count_to_completed. The itsm.itsm_incident.schedule_id_state_to_completed property allows you to specify the schedule used for calculating the period until the automatic completion.

note

Infrastructure incidents are not completed automatically as their state model does not have the Information needed state.

Close incidents automatically

---

Completed incidents, except for infrastructure incidents, are automatically moved to the Closed state if the caller provides no feedback within the specified time frame. The automatically closed incidents also get deactivated.

note

Infrastructure incidents can only be closed manually via their forms.

You can specify the number of days after which completed incidents with no caller feedback are automatically closed in the system property itsm.itsm_incident.days_count_to_solution_accept. The itsm.itsm_incident.schedule_id_to_solution_accept property allows you to specify the schedule used for calculating the period until the automatic closure.

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.