An Incident is Canceled when it is raised in error or identified as a duplicate of another incident record.

Diagram: Incident Management State Model Flow

Table: Incident State Model

Learn more here!

Service level agreements (SLAs) specify the set amount of time agreed upon to reach a particular condition, in this case, to respond to or resolve an incident.

The Priority value determines the SLA and changes during the incident lifecycle only if the priority changes.

An SLA definition is used to create and progress SLAs, enabling you to use an SLA system for your organization's tasks.

An SLA definition record defines the timings, conditions, workflows, and other information required to create and progress task SLAs.

For example, the default Priority 1 resolution (8 hour) SLA Definition defines the Task SLAs to attach to incidents with a P1 - Critical priority specifies appropriate conditions for those Task SLAs and uses the default SLA workflow to create events such as sending a notification when an incident's Task SLA reaches 50% of its allotted time.

Screenshot 1: The Task SLA Related List with a Priority 1 SLA attached to an incident

Screenshot 2: Example of a response SLA and resolution SLA for a P2 incident

Learn more here!

Here are the different close codes on a change request:

• Successful,
• Unsuccessful, and
• Successful with issues

A Change Advisory Board (CAB) definition is similar to a recurring meeting invitation. When you define a CAB definition, it determines the attributes that are associated with all CAB meetings generated from that definition.

The CAB Definition is where you define the CAB as a forum, with CAB name, members, delegates, locations, time zone, and scope of changes.

The CAB definition contains:

1. Information about the CAB forum, including the name, scope, and participants
2. Meeting schedule definitions
3. Links to meeting sessions.

Screenshot: Example of a CAB Definition record

Learn more here!

With the ServiceNow Configuration Management Database (CMDB) application, build logical representations of assets, services, and the relationships between them that comprise your organisation's infrastructure. Details about these components are stored in the CMDB, which you can use to monitor the infrastructure, helping ensure integrity, stability, and continuous service operation.

The CMDB helps ITSM processes by identifying the following:

• the respective support and approval groups,
• the business criticality of affected CIs to help in prioritisation and escalation and
• the potential upstream or downstream impacts.

CMDB provides the capability to associate configuration items (CIs) to the incident, problem, or change records but not to identify the relationship between them.

Diagram: CMDB touchpoints with ITSM processes

Learn more here!

Agents can use Incident priority to identify:

1. How quickly the service desk must address the issue.
2. The sequence in which the incident requires resolution.
3. Time available within the SLA for incident response and resolution.

Priority is based on impact and urgency where:

'Extent to which expected levels of service are affected' is considered Impact.

'Time available for repair or avoidance before impact is felt' is considered Urgency.

Screenshot: Populating Incident priority based on Impact and Urgency

Learn more here!

The taxonomy feature enables you to link an article to one or more topics from multiple taxonomies. It also helps you maintain a unified content categorisation across content types such as catalogue items, knowledge articles, and community posts.

Content Taxonomy is the application that provides the data model or the topic hierarchy and the taxonomy management (content authoring) capabilities for the unified taxonomy. The content types mapped by default are requests, articles, quick links, and employee communications. Once the plugin is downloaded, this mapping will be visible as part of the content taxonomy app in the platform.

Screenshot: The Content Taxonomy Data Model showing a unified content categorisation across different content types

Learn more here!

The personas for request management include the end user (requester), the approver, and the process user (fulfiller).

A process user fulfils requests for the end-user through a series of tasks.

They can also submit requests on behalf of the end user.

Preparing to fulfil catalogue item requests involves the following activities.

• Set up fulfilment groups to assign to tasks.
• Define the fulfilment processes using execution plans or workflows.
• Assign the fulfilment process to catalogue items.
• 
  

Learn more here!

An activity stream is a list of entries in records and conversations. Examples of activity streams include journal fields like comments and work notes that are displayed in task records and Connect Chat conversations. Activity streams are available in UI15, UI16 and the Next Experience UI (Polaris).

Activity Stream enables agents to communicate with requesters and make internal notes about the work done on a record.

The entire history of the incident record is automatically tracked and recorded in the Activity stream from creation through closure, located under the Notes tab.

There are three types of activity streams:

1. List activity stream
2. Record activity stream
3. Visual Task Boards

Screenshot: Activity stream on an Incident form

Learn more here!

When the problem and the solution have been identified, the problem is in the Investigation and Diagnosis stage of the lifecycle.

Problem Management has one single goal: Identifying and resolving the underlying issues that cause Incidents. Problem Management is a systematic, methodical process where time to resolution is less important than identifying and resolving the root cause.

Problem Management is responsible for managing the life cycle of underlying problems. State transition of a problem guides you through the stages of a problem life cycle, from creation to closure.

Screenshot: Problem Management state transitions

Learn more here!