Page History

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

Image Added

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:

Waiting

---

Waiting includes the following procedures and states: 

Procedure

Status

State	Description	Available Transitions
Investigation and diagnosis	Information Needed	If 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 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
Resolution	Postponed	The incident can be

marked 

marked Postponed if the resolving incident

resolving

should be postponed for a known period. If the incident moves to this

status, then planned resolving date must be specified in the 

state, the agent should specify resolving date in the Resubmission field.

 But

But if the incident affects business functions, then it

must

should have at least a temporary workaround.	In Progress Information Needed External Processing
Functional escalation	External Processing	If 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 3

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
Resolution	Rejected by User	If 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.

Incidents Prioritization

Incidents prioritization

Incident priority Priority of the Incident can be figured out based on its the incident impact and urgency  using using a priority matrix.

The impact of an incident indicates the level of damage that will 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.

Assigning and

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. (Non-mandatory step) complete the same step for the Assigned User field.
4. Add a user to the Assignment User filed by clicking the magnifier iconImage Added.
5. (Optional) Complete the same step for the Assigned Group field.

The incident is assigned.

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 groupThe incident is assigned.

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

1. Open the incident you want need to work on.
2. Change the desirable field(s)necessary fields.
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)Feed, in history.

The following information is displayed:

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

Activity viewview 

Image Removed

Create a "parent-child" relationship between incidents

Create a such relationship links two or more incidents between each other in a "parent-child" model.

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

1. Start creating a new incident in a way as it was described here.
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 in a way as it was described here.
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.

For your information: 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.

Create an Incident Announcement

Create an announcement informing related to 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 solving of incident 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. 

To create an incident task, please complete the following steps:

1. Open the incident you want to work on;
2. Scroll down the page, then open the Incident Task tab;
3. Fill in the form:

Number 

Available options:

Image Added

Escalation rules

There are two possible types of escalations: 

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

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

Click Save or Save and Exit to apply changes.

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 window appeared choose a necessary option and click Save.

Relationship types

Solved by Change

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

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

• .

Closure information

Based on the SimpleOne state model, when the incident was 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

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:

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 1^st level service agents are unable to solve an incident due to any reasons (lack of authority or competence), they escalate it to the 2^nd level to address.
• 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.

In SimpleOne, automatic incident escalation is implemented. How it works:

1. If the incident have not been processed for a certain period, and there is a risk of the SLA breach, then assigned person or group manager is being notified about this;
2. If the things have not been changed, then incident urgency increases, the incident rises up in line;

3. If it didn't help, then incident urgency increases again, the incident rises up in line, the assigned person or group manager is being notified about this repeatedly.

Also, you can keep the line manager of the assignee informed about the incident activities by clicking the "Notify Manager" button on the form.

One of the examples of the hierarchical escalation:

If the incident solution was rejected by the caller (state Rejected by User was set) two times, then the automatic notification is sent to the assignee' manager.

Indication

Every incident has SLA indicators quantized and tied up. They can be found at the bottom of the incident page, in the Indication Tab. This tab displays the following information:

1. Start time;
2. Has breached;
3. Stop time;
4. Business Elapsed Time;
5. Business Time Left;
6. Breach Time;

7. Pause Time.

SLA Indicators

Indicator

Description

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

In SimpleOne, SLA indicators can be determined based on three entities: field, operator and value.

You can create your own SLA indicators using the Condition Builder. To create it, navigate to the Agreements and Commitments → Timepoint Indicator and click New.

For example, you can create separate SLA indicators for incidents having an impact from "Low" to "Very High" and set a separate "Breach Time" value for them, based on your SLA agreement.