General Concepts and Procedures
This article describes general concepts and procedures that apply to various ITSM entities.
Reassign
You can reassign incidents and service requests to another user or group by clicking Reassign in the upper right corner of the form. The state of the record will automatically change to Assigned, unless it is already in this state.
Create an announcement
You can create an announcement to share important information about a certain ITSM entity with affected users. While announcements can be created for any ITSM entity, with your "out-of-the-box" solution, you can create announcements for incidents and change requests.
To create an announcement, complete the following steps:
- Navigate to the ITSM entity you need.
- Click the Create announcement in the top right corner of the form.
- Fill in the fields.
- Click Save or Save and exit to apply the changes.
You can create as many announcements as you need.
As a result, a new announcement is created in the Announcement table. It has a reference to the entity in the Related <Entity> field. This announcement record is also displayed in the Related Lists area on the entity form.
See the Announcements article to learn more.
SLA breach
You can use the SLA Breached checkbox value on the Incident (itsm_incident) and Service Request (itsm_request) lists to create reports, diagrams and filter records by this attribute. By default, the checkbox is hidden from the record forms.
When the time set in the related indication expires and the indication is In progress, the checkbox value automatically changes to true. This behavior is configured with a business rule that automatically changes the value of the checkbox.
Automatic deactivation of closed tickets
When an incident, service request or its related task moves to the Closed state, the system deactivates it (the value of the Active attribute changes to No), so that:
- All fields become read-only.
- The Closed at field displays the time when the task was set as Closed.
- Only user with admin role can make the record Active again.
There are two ways for the incidents and service requests to change the state to Closed:
- If the caller accepts the ticket resolution.
- Automatically by a scheduled event after a set period of time after the incident or service request changes its state to Completed. The system cancels the event if the state of the incident or service request has been changed during this period. These events are closing_of_an_incident for the incidents and itsm_req.auto_closing for service requests.
The system does not close the Infrastructure incidents automatically. You can only do it manually on the incident from.
Specify the period for the caller to assess the results before the deactivation in the system properties itsm.itsm_request.days_count_to_solution_accept and itsm.itsm_incident.days_count_to_solution_accept. You can select the schedule for the calculation of this period and specify the number of days before the incident or service request is automatically closed.
When a parent incident or service request becomes Closed, all of its child tasks except for the Canceled ones also become Closed.
Parent incident or service request state can only be changed to Completed if all of its child tasks are in the Completed or Canceled states.
When the child tasks of incidents and service requests move to the Canceled state, the system deactivates them (the value of the Active attribute changes to No), so that:
- The Closed at field displays the time when the task was set as Canceled.
- All fields become read-only.
The caller receives a notification when the ticket is closed automatically.
Agent and service satisfaction
The Agent satisfaction and Service satisfaction fields are present on forms to evaluate the agent performance. Both fields have the same set of values:
- Below Expectations
- Meets Expectations
- Above Expectations
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:
If the caller accepts the solution, the ticket state will be changed to Closed and the evaluation form will be opened. The values of these evaluations are connected with the values of the choice options in the agent interface:
- Below expectations = Poor
- Meets expectations = Good
- Above expectations = Excellent
The user may skip it and send the empty form without evaluation. The feedback field is optional unless at least one of the evaluations is set to Poor. In this case, the feedback field becomes mandatory:
The change of the ticket state, user evaluation and feedback message are added to the Activity Feed. The closure note is displayed in the upper right corner of the task view:
If the caller rejects the solution, the ticket state changes to Rejected by user and the caller should specify the reason for rejection. This comment is required for the completion of the evaluation procedure.
After that, the user will see the following message:
The change of the ticket state and the reason for rejection are added to the Activity Feed. The resumption message remains on the page in the upper right corner of the task view:
