You can select the ‘Assign to me’ UI action for an incident record to assign the record to yourself after passing the following checks:

• If the Assignment group field is filled in and you're part of the group, the record is assigned to you.
• If the Assignment group field is empty and you're a member of a single group, the Assignment group field is filled in, and the record is assigned to you.
• If the Assignment group field is empty and you're a member of multiple groups, you're prompted to select the Assignment group. When you manually select the Assignment group, the record is assigned to you.
• 
  

Screenshot: ‘Assign to me’ UI Action on the Incident form

Learn more here!

You will need to involve the right stakeholders to determine the specific CI information required to support these capabilities and build organisational buy-in.

This stakeholder group should include the process owner, process manager, and other subject matter experts for each process.

Diagram: CMDB Architecture

Learn more here!

Administrators can manage all aspects of the Service Catalog application, including catalogs, categories, catalog items, and advanced functions, such as scripting or creating business rules.

Catalog administrators can manage all aspects of the Service Catalog application...except scripting functions.

Here are the key change management features:

• Standard Change Catalogue,
• Standard Change Request and Approval Process,
• Workflows per Change Type,
• State Model Management,
• Risk and Conflict Detection Analysis,
• Change Advisory Board Workbench,
• Blackout and Maintenance Schedules, and
• Discovery and SAM Integrations.

DevOps works to automate deployment and testing.

Learn more here!

A bundle is a predefined grouping of catalogue items that allows you to select the products and services you need quickly.

An order guide provides a series of questions that, when answered, offers a list of recommended products and services that may help you fulfil your need.

A shopping cart is not predefined, and a multi-row variable set can be part of a catalogue item.

Learn more here!

You can use multi-row variable sets to capture data in a grid layout; however, there are some limitations:

• They cannot be displayed when added within a container,
• They are not visible in the variable summarizer, and
• You cannot add variables with read roles.

You can use a multi-row variable set (MRVS) to capture variable data in a grid layout while submitting a catalogue item request for a group of entities. For example, for HR, during the reorganisation of employees, a single record producer should be able to capture the relevant information, such as the department and manager for a group of employees. Also, when you request a catalogue item to order virtual machines and servers, configuration options should be captured as a single request. In this case, a requester can define multiple hardware units as rows and their configuration options as columns of an MRVS.

Learn more here!

Configuration Management System (CMS) is a set of tools and databases used to manage an organisation's configuration data.

As per ITIL, Configuration Management System is a much broader system that combines many different data repositories.

Diagram: Configuration Management and the CMDB Architecture

Learn more here!

When you resolve a parent incident, the following activities will automatically occur:

• The resolution code is copied to the child incident
• Resolution information is copied to the child incident
• Activity stream of child incidents are updated with parent's incident state of Resolved and parent's resolution information from the resolution tab
• State on child incidents is updated to Resolved.

The parent and the child incidents are synchronised such that the state of a child incident changes depending on the state of the parent incident.

Table: Parent-Child state synchronisation

For incidents linked through a parent/child relationship, all child incidents are also resolved when you resolve the Parent incident. The Resolution code and Resolution notes are copied from the parent incident to the child incidents.

Screenshot: Resolving a parent incident cascaded to the child incidents with an additional comment to notify the callers

Learn more here!

The resolution code for the problem record should be Risk Accepted if the permanent solution should wait until a future date.

Following the root cause analysis (RCA), a determination may be made to NOT implement a permanent fix that removes the root cause from the environment. In some situations, members of the leadership team may choose to accept the risk of continuing with the workaround identified in the known error record or accept the risk and do nothing further. This is often due to high cost vs. low benefit.

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

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

• Fixed Applied
• Risk Accepted
• Canceled
• Duplicate

Screenshot 1: Accepting risk on a problem record

Screenshot 2: List of problems with the 'Risk Accepted' Resolution code

You can create change tasks for a change request. A change task is a piece of work related to the change request. For example, there can be tasks to plan the change, implement the change, and test, and review the work.

Implementation and Testing change task types are typically completed during the change implementation window (i.e., between the planned start and end dates).

Planning change task type is usually completed before approvals are made, and Review change task type is usually following implementation; for example, during the PIR.

Screenshot: Different change task types

Learn more here!