Fixing the immediate issue is associated with the resolution and closure stage in the Incident Management Lifecycle, as it is the first activity toward restoring the service.

An incident is considered resolved when you provide the user with a temporary workaround or a permanent solution for the issue.

The escalators stop when an incident is resolved, and the caller can review the resolution. Suppose the caller is satisfied with the resolution. In that case, the caller can close the incident, or it is auto-closed after a particular time based on the incident auto-close properties.

If the cause of an incident is understood but cannot be fixed, the service desk can create a problem from the incident to find the root cause of the issue. The problem is then evaluated through the problem management process.

If the incident creates the need for a change in IT services, the service desk can generate a change from the incident, which is evaluated through the change management process.

Diagram: The process review for incident lifecycle

Learn more here!

Standard changes are predefined, pre-authorised changes that are considered to be relatively low risk.

They are frequently implemented and have repeatable implementation steps.

They also have a proven history of success.

All the other options are scenarios of an emergency change.

Screenshot: Example of a standard change request

Learn more here!

Configuration Item [cmdb_ci] table stores the basic attributes of all the configuration items.

• Base Configuration Item [cmdb] is the base CMDB table for non-IT CIs.
• CI Relationship [cmdb_rel_ci] contains CI relationship data.
• Configuration File [cmdb_ci_config_file] is one of the CI types.

Diagram: CMDB CI schema related to common core and non-core tables

Learn more here!

The Predictive Intelligence classification framework enables you to use machine-learning algorithms to set field values during record creation, such as setting the incident category based on the short description. You can train predictive models, so they act as an agent to automatically categorise and route work based on your past record-handling experience.

Predictive Intelligence enables you to train predictive models and machine-learning solutions that you can apply to your business processes.

You can also train the machine-learning (ML) algorithm through two solution definitions, Incident Configuration Item and Incident Service, to predict the Configuration Item and Service fields' value based on the value in the Short description field.

Note: Both Predictive Intelligence and Incident Management must be active in the instance.

Image: Predictive Intelligence classification framework

Learn more here!

A problem task is the smallest unit of work that you should perform to complete a problem. You can divide your problem into multiple problem tasks which you can easily assign to different assignment groups or users.

A problem task tracks a unit of work that supports the parent.

There are two types of problem tasks:

• Root Cause Analysis: Tasks where you investigate the root cause of a problem and find a resolution for the problem
• General: All other tasks

Screenshot 1: The interceptor when creating a new problem task

Screenshot 2: List of problem tasks grouped by their type

Screenshot 3: Example of a problem task of type 'Root Cause Analysis'

Learn more here!

You can configure widget instance options for the knowledge sort widget on the Knowledge Management Service Portal search results page.

The search results page uses the Knowledge Result Sort widget to provide sort options for the returned list of results. You can use the widget instance options to customise the sort options.

You can sort knowledge articles by Relevancy, Views, Newest and Alphabetical attributes in ascending and descending orders when searching for a knowledge article on the Knowledge portal.

• Views: sorts by the number of article views.
• Newest: sorts by the date created or updated.
• Alphabetical: sorts alphabetically by the article Short description field.
• Relevancy: sorts by relevance to the search term.

Additionally, you can refine the article list by applying filters such as their category and rating.

Screenshot: Sorting knowledge article search results on the Knowledge Portal

Learn more about:

• Knowledge Management Service Portal search results page features
• Configuring sort widget instance options

Following buttons / UI Actions on the Problem record change the state to Closed:

• Cancel
• Mark Duplicate
• Accept Risk
• Complete

Then, the action is recorded in the Resolution code.

If you acknowledge the problem, but there is no permanent resolution to the problem, click 'Accept Risk'. The problem directly enters the 'Closed' or 'Resolved' state with the 'Resolution code' as 'Risk accepted'.

• Note 1: Whether the problem enters the 'Closed' state or the 'Resolved' state depends on the property Accept Risk moves the Problem to the Closed state instead of the Resolved state (problem.acceptrisk.move_to_closed).

If there is an existing problem with a similar issue, click 'Mark Duplicate'.

• Note 2: When you mark a problem as duplicate, the related records from the duplicate problem are moved to the existing problem.

Screenshot 1: A problem in Assess state with options to cancel and mark as duplicate

Screenshot 2: Selecting the 'Mark Duplicate' UI action on a problem record

Screenshot 3: The problem moved to the Closed state after selecting the 'Mark Duplicate' UI action

Screenshot 4: List of closed problems with their resolution code

Learn more here!

On hold is not a defined state within the change lifecycle; however, a change request can be placed on-hold, except when it is in the New, Canceled, or Closed state.

This is done by checking the On Hold box on the change request form and completing the mandatory On Hold Reason field.

Screenshot: Placing a change request on hold in the Implement state

Learn more here!

A Standard change is a predefined, pre-authorised change considered to be relatively low risk.

It is frequently implemented, has repeatable implementation steps and has a proven history of success.

A Standard change was initially implemented as a normal change or standardised through the use of templates.

Approved standard change requests can be predefined in a catalogue of templates to make accessing and requesting a standard change more efficient. This ability also enables the Change Management team to control the changes that are authorized as standard.

Screenshot: Example of a standard change request

Learn more here!

Assignment Group may be used by change requests for routing of change requests and change tasks.

You can populate the Assignment group field automatically based on the support group available for the respective configuration item (CI). If the CI does not have any support group, then the field gets populated with the support group available for service offerings. The business rule 'Populate Assignment Group based on CI/SO' triggers the functionality when an incident, problem, or change request is created or updated and when the 'Assignment group' and the 'Assigned to' fields are empty. The following properties identify the field whose value populates the 'Assignment group' field:

• com.snc.change_request.ci_assignment_group.field_name: This change property identifies which CI field populates the Assignment group field.
• com.snc.change_request.service_offering_assignment_group.field_name: This change property identifies which service offering field populates the Assignment group field.
• 
  

Learn more here!