Versions Compared

Old Version 116

changes.mady.by.user Dina Baksheeva

Saved on

compared with

New Version Current

changes.mady.by.user Dina Baksheeva

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

This section focuses on Incidents processing by the agentsagents. You can see the incident state model on the diagram below.

Tip

Role required: incident_manager.

State Flow

Anchor
Image Removed
state model
*This
state model
 is valid for End-User incidents.
Image Added

Note

Infrastructure Incidents do not

have 

have the Rejected by User state.

The states of Incident Processing can be divided into: 

  • State Flow. When the incident is in the State Flow state, for example, In Progress, SLA indicators count down the time related to the incident processing until the SLA breaches.
  • Waiting. When the incident is moved to the Waiting status (for example, Information Needed), all SLA indicators related to the incident stop the countdown.

State flow

State Flow includes the following procedures and states:

Procedure

Status

Description

Procedure

State

Description

Available Transitions
LoggingRegisteredThe incident is recorded (via phone/email/Self-Service Portal) but not yet categorized.
  • Assigned
  • In Progress
CategorizationAssignedThe incident is categorized and assigned to a relevant person or group.
  • In Progress
  • Information Needed
  • Completed
ResolutionIn Progress
The

A person started working on the issue.

NoteWhen Assigned User changes to another person, the Incident state changes from the In Progress to Assigned value.

  • Assigned
  • Postponed
  • Information Needed
  • External Processing
  • Completed
ClosureCompleted

An incident is

considered to be

resolved when

an agent comes up with a temporary workaround or with a permanent solution for this issue. In this case, he/she must change the status to 

the agent provides temporary workarounds or permanent solutions. The agent changes the state to Completed so that the caller could

perform the tests. If the tests are successful, the incident should be marked as 

 decide on the results. 

The caller receives a notification. They are asked 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

should be marked as 

is Rejected by User.

Also, when incident is completed, the caller can evaluate agent's performance and the service level on the whole. For this, please follow these steps:

  1. The agent changes the incident state to Completed.
  2. The caller receives a notification where he is asked to evaluate the agent job and the service level.
  3. The caller follows a link in the notification and evaluates these parameters. There are three values which correspond to three system values:
    1. Below Expectations
    2. Meets Expectations
    3. Above Expectations.
  • Assigned
  • In Progress
  • Rejected by User
  • Closed
Closed

There are Agent Satisfaction and Service Satisfaction fields on the form to evaluate the agent performance. Each field has three following values: 

  • Below Expectations
  • Meets Expectations
  • Above Expectations.

Image Added

On the Self-Service Portal, the caller can evaluate results. Values of these evaluations are connected to the values of choice options.

  • Below Expectations = Disappointed
  • Meets Expectations = Satisfied
  • Above Expectations = Very Pleased. 

Image Added

If an incident is

ClosureClosedAfter the incident caller is satisfied with the incident solution, he can close the incident (mark it as Closed and (optionally) evaluate the agent performance by grading "Agent Satisfaction" and "Service Satisfaction"). If the incident was

not closed after it was marked

as 

as Completed, 

then

it can be closed automatically over an adjustable timeframe that is set in system properties.



Info

Only the incident caller has the right to close the incidents; this is the best ITSM practice. But in SimpleOne, this rule does not affect infrastructure incidents. The incidents of this type can be closed only by the responsible person after performing the testsexamination.

Waiting

Statuses

Waiting includes the following procedures and states: 

Procedure

Status

State

Description

Available Transitions

Investigation and diagnosisInformation NeededIf the
issue description
issue description is not clear enough,
then
the agent
has to
can request additional information by changing the incident
status to 
state to Information Needed.
 Once
Once the information is received,
the status has to be changed
the agent should change the state to the previous one.

  • Assigned

  • In Progress
  • Postponed
  • External Processing
ResolutionPostponed

The incident can be marked Postponed if the resolving incident should be postponed for a known period. If the incident moves to this

status, then planned resolving date must be specified

state, the agent should specify resolving date in the Resubmission field. But if the incident affects business functions, then it

must

should have at least a temporary workaround.

  • In Progress
  • Information Needed
  • External Processing
Functional escalationExternal ProcessingIf the incident solving requires 3rd
 party
 party engaging, then, after
referrals
reassignment, the incident
status must
state should be changed
to 
to External Processing.
 And after this 3rd party
After the 3rd party engaging is over, the agent should change the incident state and the assigned user
should be changed
to the previous
one
ones.
  • In Progress
  • Postponed
  • Information Needed
  • Completed
ResolutionRejected by UserIf the
caller is
caller is not
satisfied with
satisfied with the agent
work
working on the incident after completing it,
then he can
they can change the
status to 
state to Rejected by User to address the defects.
  • Assigned
  • In Progress
  • Completed

Incidents

Prioritization

prioritization

Incident Priority priority can be figured out based on its the incident impact and urgency using urgency using a 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:

  1. Low
  2. Medium
  3. High
  4. Very High.

The urgency of an incident indicates the measure of time until an incident has an impact impacts on the business. In SimpleOne, the urgency can be categorized as:

  1. Low
  2. Medium
  3. High
  4. Very High.

Based on the priority, incidents can be categorized as:

  1. Low
  2. Moderate
  3. High
  4. Critical.

Anchor
matrix
matrix
Excerpt Include
Priority Management
Priority Management
nopaneltrue


Assigning and

Updating Incidents

updating incidents

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

  1. Open Navigate to Incident Management → All Incidents and open the incident you want to work on.
  2. Find the Assignment Group field, then click the magnifier icon to select a group to assign the incident to.
  3. Add a user to the Assignment User filed by clicking the magnifier iconImage Added.
  4. (Optional) Complete (Non-mandatory step) complete the same step for the Assigned User fieldGroup field.

The incident is assigned.

To perform any updates in the incident, please complete the following steps:

  1. Open the incident you want to work on.
  2. Change the desirable field(s).
  3. Click Save or Save and Exit to apply changes.

Your changes will be displayed in the Activity log, that is located in the Notes tab (scroll down the page).

The following information is displayed:

  1. Update author
  2. Field updated
  3. New field value
  4. Old field value.

Activity view

Image Removed

Create a "parent-child" relationship between incidents

Create such relationship to link two or more incidents with each other in a "parent-child" model.

To create a child ticket, please complete the following steps:

  1. Start creating a new incident.
  2. Fill in the form, then scroll down the page and open the Related Records tab.
  3. Click a magnifier icon next to the Slave Incidents field. The incidents list will appear.
  4. Select desired incidents from the list and click the Select Items button. You can choose more that one item, in this case, all of them will be slaves for the master incident.
    1. The Level of Dependency field is automatically populated with the Master value and remains read-only.
  5. Click Save or Save and Exit to apply changes.

If you need to make an existing incident child for another one, then you can skip step 1.

To create a parent ticket, please complete the following steps:

  1. Start creating a new incident.
  2. Fill in the form, then scroll down the page and open the Related Records tab.
  3. Click a magnifier icon on the Master Incident field.
  4. Select an incident you need to be a parent for this one.
    1. The Level of Dependency field is automatically populated with the Slave value and remains read-only.
  5. Click Save or Save and Exit to apply changes.
Info

You can also use an autosuggest feature when choosing records in reference fields, such as Master Incident or Slave Incidents fields. For this, just start typing an incident number or incident subject.

If you need to make an existing incident parent for another one, then you can skip step 1.

Tip
titleMaster and Slave Incidents

You can close all slave incidents related to the master incident with a bulk action without navigating to a form of every slave incident and manually closing it. For this, please complete the steps below:

  1. Make sure that the master incident is in the Completed state.
  2. Navigate to the Related Records tab and click the Close all Slave Incidents button.

After that, the state for all slave incidents will be changed to Completed, too. The closure notes and other service information will be transferred from the master incident.

Also, when you comment on a master incident, the comment you made is transferring into slave incidents in two ways depending on the comment type:

  1. The comment left in the Work Notes field of the master incident is copied into relevant fields of all slave incidents.
  2. The comment left in the Additional Comment field of the master incident is copied into relevant fields of all slave incidents, and in addition, a comment announcing notification is sent to the incident caller.

Create an Incident Announcement

Create an announcement to inform about the Incident being processed.

To create an Incident announcement, please click the Create Announcement button in the Incident form.

In there, two types of announcements are available:

  • Recovery – this type of announcement informs that some service or CI recovery activities have been started.
  • Completion Recovery – this type of announcement informs that some service or CI recovery activities are over.

Create an Incident Task

If incident solving requires the participation of various departments, then you can create Incident Task for each of them. They will be related to the parent incident, but not like in the "master-slave" model. The better example is the "parent-child" model. 


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 state of the incident 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 incident and who have the itsm_agent role, or belong to the assigned group.

To perform any updates in the incident, please To create an incident task, please complete the following steps:

  1. Open the incident you want need to work on.
  2. Scroll down the page, then open the Incident Task tab.
  3. Fill in the Change the necessary fields.
  4. Click Click Save or Save and Exit to apply changes.
FieldMandatoryDescription

Number 

YThis field is populated automatically.ParentYThis field is populated automatically with the number of the parent incident.StateN

Available options:

  • Registered
  • In Progress
  • Completed
  • Cancelled.
Assigned UserY

Choose a responsible person you wish to assign the task to.

Note

When an incident has been assigned to a responsible user, then the Assigned Group field becomes non-mandatory. The same goes for other task objects, like change requests, or service requests.

Assigned GroupY

Your changes will be displayed in the Activity Feed, in history.

The following information is displayed:

  1. Update initiator
  2. Field updated
  3. New field value
  4. Previous field value.

Activity view 

Image Added

Escalation rules

There are two possible types of escalations: 

  • Functional. When 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. It is an escalation up to the management

Choose a responsible group you wish to assign the task to.

Note

When an incident has been assigned to a responsible group, then the Assigned User field becomes non-mandatory. The same goes for other task objects, like change requests, or service requests.

SubjectYSpecify the task subject.DescriptionNDescribe the task by giving more details.Followers listNIn there, users list who follow the task for tracking updates is displayed.Schedule tabPlanned Start DatetimeNThe date when you want the assigned person to start working on this task.Planned End DatetimeNThe date you want this task to be finished (completed and closed).Actual Start DatetimeNThe date when the assigned person started to work on this task. This field must be filled by the agent.Actual End DatetimeNThe date when the assigned person finished the work on this task. This field must be filled by the agent.
Info

You can create as many Incident Tasks as you need. 

Create Relationships

You can create relationships between incidents and other types of tasks. For this, please complete the following steps:

  1. Open the incident you want to work on.
  2. Scroll down the page, then open the Related Records tab.
  3. You can create these types of relationships:
    1. Solved by Changes
    2. Caused by Changes
    3. Related Problems
    4. Known Error
    5. Related Inquiry
    6. Slave Incidents

    7. Master Incident

    8. Related Articles.
  4. To create these relationships, please complete the steps below:
    1. Click a magnifier icon next to the appropriate field.
    2. In the appeared window choose a necessary option and click Save.

Relationship types

TypeDescription

Solved by Change

The incident is solved / can be solved by the Change Request specified.

Caused by ChangeThe incident is caused by the Change Request specified.Related ProblemsThe incident is related to the Problems specified.Known ErrorThe incident is a Known Error, it has a recorded root cause and a workaround.Related InquiryThe incident is related to the Inquiry specified.Slave IncidentsThe incident has one or more child incidents (see above on this page).

Master Incident

The incident has a master incident (this essence is opposite to the child incidents).

Related ArticleThe incident is related to the Knowledge Base Article specified

  • .

Closure information

Based on the SimpleOne state model, when the incident is resolved, it must should be marked as Completed, that . It will denote the incident closure. Also, the agent must should provide the following details:

  • Closure Code
  • Closure Notes.

Closure notes

Closure Code

In the Closure Notes field, you need to put down information on works performed and other information related to this incident. 

Closure code

This code specifies an option of for the closure.  SimpleOne has SimpleOne has the following options:

Option

Description

Solved 1st level

The incident was solved by the

1st level of service

agents without

agents solved the incident without functional escalation.

Solved 2nd level

The incident was solved by the

2nd level of service agents solved the incident (the 1st level of service agents was unable to solve it).

Not Solved (Refused)

Agents

couldn't

could not reproduce the incident and

didn't

did not find any disfunction.

Not Solved (Dropped)

This closure code is chosen when the request is not an incident at all

(

, for example, it

's a Change Request)

is a Change Request.

Not Solved (No User Reaction)

This closure code is chosen when the user

didn't

did not provide additional information after

he was

they were asked about this during the Information Needed phase.

Not Solved (Other)

This closure code is

meant to be

for all other reasons.

Not Solved (Workaround)

This closure code means that the incident has no permanent solution, but a temporary workaround related to the Known Error.

Closure Notes

In this field you need to put down information on works performed, and maybe other information related to this incident. 

Escalation Rules

There are two possible types of escalations: functional and hierarchical.

  • Functional escalation is when 1st level service agents are unable to solve an incident due to any reasons (lack of authority or competence), they escalate it to the 2nd level to address.

    • Processing 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

    Hierarchical escalation is typically required when an incident is of a serious nature or a set of incidents may take an excessive amount of time. It's an escalation up to the management

    .

    Table of Contents
    absoluteUrltrue
    classfixedPosition

    ...