Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Merged branch "DOC0000226" into parent


Tip

Role required: incident_manager.

Create an incident announcement


You can create an announcement to inform that the incident is processed.

To create an Incident announcement, please complete the following steps: 

  1. Navigate to Incident Management → All Incidents and open the incident you need.
  2. Click the Create Announcement at the top right corner.
  3. Fill in the fields. 
  4. Click Save or Save and Exit.

As a result, a new announcement is created in the Announcement table. It also has a reference to the incident in the Related Incidents field. This announcement record is also displayed in the Related Lists area on the incident form.

Info

You can create as many incident announcements as you need. 

Incident Announcement form field

FieldMandatoryDescription

Number 

YContains an announcement number in ANCMXXXXXXX format. This field is populated automatically.
StateY

Announcement state. This field is populated automatically with New as it is just created. Other options:

  • Review – the announcement must be reviewed. After setting this state, notifications are sent to all emails specified in the Reviewer’s Email field.
  • Published – the announcement is displayed on the Self-Service Portal and/or sent via email. Select via Email and/or via Portal checkboxes accordingly. 
  • Inactive – the announcement is inactive. It is not displayed on the Self-Service Portal and/or not send via email.
Tip

Only active announcements {state IS Published^via Portal IS Yes} are displayed to Portal users.


Related IncidentYThis field is populated automatically with the number of the incident.
Announcement Type Y

Available options:

  • Recovery– informs that some service or CI recovery activities have been started.
  • Completion Recovery – informs that some service or CI recovery activities are over.
ServiceYService affected by the incident.
Recipient EmailNSpecify the email of the announcement recipient. You can add more than one email, separated by commas.
Reviewer's EmailNSpecify the email of the announcement reviewer. You can add more than one email, separated by commas.
via EmailNSelect this checkbox to send this announcement via email. It will be sent to all addresses specified in the Recipient Email field.
via PortalNSelect this checkbox to display this announcement on the Service Portal in the Portal Announcements area.
SubjectYThis field will be populated automatically with the incident subject.
Announcement BodyNType the message you need to share with users about this incident. You can design the announcement body using the built-in editor functionality, such as formatting, working with tables and media, lists, styles, and headings.
SignatureNReference to the Announcement Signature.
DescriptionN

Add a description.

Create relationships


You can create relationships between incidents and other types of tasks.

Relationship types

TypeDescription
Related ProblemsThe incident is related to the Problems specified.
Related InquiryThe incident is related to the Inquiry specified.
Solved by ChangesThe incident is solved / can be solved by the Change Request specified.
Caused by ChangesThe incident is caused by the Change Request specified.
Master Incident
The incident has a master incident (this essence is opposite to the child incidents).
Slave IncidentsThe incident has one or more child incidents (see above on this page).
Related ArticlesThe incident is related to the Knowledge Base Article specified.
Known ErrorThe incident is a Known Error. It has a recorded root cause and a workaround.

To create relationships, please complete the following steps:

  1. Navigate to Incident Management → All Incidents and open the incident you need.
  2. Open the Related Records tab.
  3. Click the magnifier icon Image Addednext to the appropriate field.
  4. In the appeared window, choose the necessary option.

  5. Сlick Save to apply changes.

"Parent-child" relationship between incidents
Anchor
parent child incident
parent child incident


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

To make the current incident parent to other existing incident, please complete the following steps:

  1. Navigate to Incident Management → All Incidents and open an incident that you want to be a parent incident.
  2. Open the Related Records tab.
  3. Click the magnifier icon Image Addednext to the Slave Incidents field. The incidents list will appear. 

    Tooltip
    onlyIcontrue
    appendIconinfo-filled
    iconColorblue

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


  4. Select necessary incidents from the list. Click on the checkbox icon Image Addedon the left.
    • You can choose more than one item, all of them will be slaves for the master incident.
  5. Click the Select Items button at the top.
    • The Level of Dependency field is automatically populated with the Master value and remains read-only.
  6. Click Save or Save and Exit to apply changes.

To make the current incident child to other existing incident, please complete the following steps:

  1. Navigate to Incident Management → All Incidents and open an incident that you want to be a child incident. 
  2. Open the Related Records tab.
  3. Click the magnifier icon Image Addedon the Master Incident field.
  4. Select an incident you need to be a parent for the current incident.
    • 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.

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. 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.

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:

  • The comment from the Work Notes field of the master incident is copied into relevant fields of all slave incidents.
  • The comment from the Additional Comment field of the master incident is copied into relevant fields of all slave incidents. A comment announcing notification is sent to the incident caller.

Create an incident task


If incident solving requires various departments' participation, you can create an incident task for each of them. They will be related to the parent incident, but not like in the "paren-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 to Related Lists.
  3. Open the Incident Task tab.
  4. Click New and fill in the fields.

  5. Click Save or Save and Exit to apply changes.
Info

You can create as many incident tasks as you need. 


FieldMandatoryDescription

Number 

YThis field contains a change request task number in CHGXXXXXXX format. It is populated automatically.
ParentYThis field is populated automatically with the number of the parent incident.
StateN

Available options:

  • Registered
  • In Progress
  • Completed
  • Canceled.
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 Assignment Group field becomes non-mandatory.

There is a dependence between Assigned User and Assignment Group fields. To learn more, please refer to Restrictions for assignment

Assignment GroupY

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.

There is a dependence between Assigned User and Assignment Group fields. To learn more, please refer to Restrictions for assignment

SubjectYSpecify the task subject.
DescriptionNDescribe the task by giving more details.
Followers listNThe field displays the list of users who follow the task for tracking updates.
Schedule tab
Planned Start DatetimeNThe date when the assigned person is supposed to start working on this task.
Planned End DatetimeNThe date when the task should be in Completed or Closed.
Actual Start DatetimeNThe date when the assigned person started to work on this task. The agent should fill in this field.
Actual End DatetimeNThe date when the assigned person finished the work on this task. The agent should fill in this field.

Incident State Model *

Image Removed

* This state model is valid for End-User incidents. Infrastructure Incidents do not have Rejected by User state.

Excerpt

The states can be divided into State Flow and Waiting statuses. The difference is that when the incident is in the State Flow state (for example, In Progress), SLA indicators are continuing to count down the time related to the incident processing. For example, it can be the time until the SLA breached (the Business Time Left indicator). But when the incident is moved to the Waiting status (for example, Information Needed), all SLA indicators related to the incident stop the countdown.

SLA-based Statuses

Status

Description

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

The responsible person has started working on the issue.

Note

When Assigned User changes to another person, the incident state changes from the In Progress to Registered value.

  • Assigned
  • Postponed
  • Information Needed
  • External Processing
  • Completed
CompletedAn 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 Completed so that the caller could perform the tests. If the tests are successful, the incident should be marked as Closed; otherwise, it should be marked as Rejected by User
  • Assigned
  • In Progress
  • Rejected by User
  • Closed
ClosedAfter the incident caller is satisfied with the incident solution, he/she could 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 Completed, then it can be closed automatically over an adjustable timeframe.
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 tests.

Waiting Statuses

Status

Description

Available TransitionsInformation NeededIf the issue description is not clear enough, then the agent has to request additional information by changing the incident status to Information Needed. Once the information is received, the status has to be changed to the previous one.
  • Assigned

  • In Progress
  • Postponed
  • External Processing
Postponed

The incident can be marked Postponed if the incident resolving should be postponed for a known period. If the incident changes to this status, planned resolving date must be specified in the Resubmission field. But if the incident affects business functions, then it must have at least a temporary workaround.

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



    Table of Contents
    absoluteUrltrue
    classfixedPosition

    ...