Incident Priority values are based on Impact and Urgency and may be updated in the Priority Data Lookups table.

Priority is used for SLAs, but SLAs are not driving the Priority.

VIP does not factor into determining priority.

The Catalog module (on the menu) is a shortcut to display the primary Service Catalog to begin browsing items and services.

The Catalogs module displays all available Service Catalogs, organised by the intended audience.

The Service Catalog is the primary catalog and contains items and services available to end-users.

The home page for a service catalog provides the primary front end for ordering items within that catalog. You can configure various elements of the pages within the Service Catalog.

Note: End users can access the catalog through the customisable user home page, or with content management pages that use content blocks for categories.

Screenshot: Accessing the Service Catalog on the platform via the Catalog menu item

Learn more here!

Here are the Major Incident States:

• Proposed,
• Accepted,
• Rejected, and
• Canceled.

Notes:

• If you cancel an incident and the major incident state is in the Proposed or Accepted state, the major incident state changes to Canceled.
• Setting the incident auto-closure property 'Enable auto closure of incidents based on Resolution date' to 'No' will make auto closure run based on the Updated date; however, it does not close any incident record that is accepted as a major incident.
• Users with the major_incident_manager or admin role must close a major incident manually after validating the resolution and when the major incident is in the Resolved state.
• If an incident was promoted as a major incident, then an ESS user cannot resolve, close, or reopen the incident.

Screenshot: Dictionary entry for major incident states

Diagram: Major Incident Management State Model

Learn more here!

Logging the incident is associated with the creation and classification stage in the Incident Management Lifecycle.

Incidents move through a basic process that includes these stages:

• Creation and Classification: Following the detection of an issue, create a new incident, or locate one that was submitted by the end-user, created automatically, or generated through another application. Document the details of the incident and assign it to the appropriate group and/or User.
• Investigation and Diagnosis: Investigate the incident by analysing/diagnosing the issue in working towards restoring normal service to the end-user. At each step throughout your investigation, you should update the incident with your findings/activities,
• Resolution and Closure: To resolve an incident, you should restore normal service to the end-user with a solution or workaround. You should also update the record with the details of your activity and communicate the resolution with the customer. If necessary, create related records such as a problem, change, or request. The incident closes automatically after a set period if there is no objection/challenge from the end-user.

Image: Incident Lifecycle process review

Learn more here!

The knowledge article view page in Knowledge Management Service Portal displays the knowledge article details, including the article number, short description, and article content. You can also click Copy Permalink to copy the URL of the latest article version to the clipboard.

Using a permalink is the best way to share a knowledge article with another user.

Screenshot: Copying the URL of the latest version of the knowledge article on the Service Portal

Learn more here!

A Request (REQ) record, a Requested Item (RITM) record and one or more Service Catalog Task (SCTASK) records are created when an order is placed for a catalogue item.

Diagram: Service request hierarchy

Learn more here!

There are different methods to populate the assignment group in an Incident record:

Manual selection, Assignment rules, Data lookup rules, and Script.

On-call scheduling is a method to populate the Assigned to field in an Incident record.

You can create a major incident candidate in multiple ways. After a major incident candidate is created, the major incident manager evaluates the candidate and decides whether the candidate should be promoted to a major incident.

Role required: itil, sn_incident_write, or admin

Anyone with the itil role can create a major incident candidate or propose an existing incident as a major incident candidate.

All candidates will need to be reviewed and accepted before becoming a major incident.

You can perform any of the following actions:

• Create major incident trigger rules
• Propose an incident as a major incident candidate manually
• Create a candidate from application navigation

Screenshot: Promoting an incident to Major Incident

Learn more here!

Here are the different resolution codes used when closing a Problem record:

• Fix Applied
• Risk Accepted
• Canceled
• Duplicate

Here are some of the different scenarios:

• If you acknowledge the problem but there is no permanent resolution to the problem, you click 'Accept Risk'.
• If there is an existing problem with similar issue, you click 'Mark Duplicate'.
• If the problem is not a valid problem, you click 'Cancel'.
• If you fixed the problem with a permanent resolution, you click 'Resolve'.

Once selected, the problem 'Resolution code' is populated automatically, depending on the scenario.

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

Screenshot 2: Problem moved to the Closed state after selecting the 'Mark Duplicate' UI action

Screenshot 3: List of closed problems with their resolution code

Learn more here!

You can move problem tasks from a problem record that is marked as a duplicate of the original problem record. This will enhance the user experience and performance with asynchronous behaviour in the movement of related records, such as moving incidents and problem tasks on a duplicate problem record to the original problem record.

You can select the ‘Assign to me’ UI action for a problem record to check if you are part of the assignment group.

The ‘Assign to me’ UI action only assigns the Problem to someone in the Assignment group.

Suppose you have customised the Task UI action or any of its extended tables or created new UI actions with the Overrides value pointing to the Task UI action. In that case, you must perform the following actions to avoid seeing two Assign to me UI actions on your extended table forms:

• Set the Action name UI action to task_assign_to_me.
• Remove the Overrides value for extended tables.

Screenshot: Problem Related List Properties with their default values

Learn more here!