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 announcements

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: 

  1. Navigate to the ITSM entity you need.
  2. Click the Create Announcement in the top right corner of the form.
  3. Fill in the fields. 
  4. Click Save or Save and Exit.

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.

Form fields 

FieldMandatoryDescription

Number 

YThis field contains an announcement number in ANCMXXXXXXX format and is populated automatically.
StateY

Announcement state. This field is populated automatically with New when the announcement has just been 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 the via Email and/or via Portal checkboxes, accordingly. 
  • Inactive – the announcement is inactive. It is not displayed on the Self-Service Portal and not sent via email.

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

Related <Entity>YThis field is populated automatically with the number of the entity.
Announcement Type Y

Available options:

  • Recovery – informs that some services or CI recovery activities have been started.
  • Completion Recovery – informs that some services or CI recovery activities are over.
  • Maintenance – informs about updates, backups, or maintenance. 
  • Urgent Maintenance – informs about an unexpected breakdown.
  • General Information – shows notifications.
ServiceYSpecify the service affected by the entity.
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.
SubjectYThis field is populated automatically with the subject of the entity.
Announcement BodyNType a message about the entity to share with the affected users. You can design the announcement body using the built-in editor functionality, such as by formatting the text, working with tables and media, lists, styles, and headings.
SignatureNReference to the Announcement Signature.
DescriptionN

Add a description for the announcement.

via EmailNSelect the checkbox to send this announcement via email. It will be sent to all addresses specified in the Recipient Email field.
via PortalNSelect the checkbox to display this announcement on the Self-Service Portal in the Portal Announcements area.

Archiving

When you set the Closed state for incidents, service requests and their related tasks, the system archives them, so that:

  • The Active attribute is set to No.
  • 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 archiving 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/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 you set the Canceled state for the child tasks of incidents and service requests, the system archives them, so that: 

  • The Closed at field displays the time when the task was set as Canceled
  • The Active attribute is set to No.
  • All fields become read-only.

The caller receives a notification when the ticket is closed automatically.


Agent Satisfaction and Service Satisfaction fields

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 on the task view. This option appears if the incident state is Completed. The caller can accept or reject the solution:

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:

  • No labels