User Criteria [user_criteria] defines conditions evaluated against users to determine which users can access catalogue items.

You can apply several user criteria records to a single catalogue item or category. In this situation, users match only one of these criteria records to have access.

When creating user criteria for your system, consider the following recommendations.

• Design Criteria for Reuse: Ensure you design user criteria for maximum reuse. Create user criteria records with common sets of conditions matching your organisation's requirements. Allow them to be shared across as many items and categories as possible rather than creating multiple similar criteria records for individual items and categories.
• Naming conventions: Give each user criteria record a meaningful name to help you determine the function for that record. For example,
• Users in company Cloud Dimensions AND in Sydney
• Users in company Cloud Dimensions OR in Sydney
• Users belonging to the Group Development, IT, or Sales
• Users with role itil, asset_manager, or catalog_admin
• Test user criteria on a development or test instance, and then transfer the records from the user criteria tables and catalogue records to your production instance using update sets.

Learn more here!

The publishing and retirement processes for a knowledge article are controlled by workflows defined for the knowledge base that the article belongs to.

You can assign different workflows to each Knowledge Base.

You can use one of the default workflows or create your workflows to define custom publishing and retirement processes for different types of knowledge.

Screenshot: Configuring the publish and retire workflows for a Knowledge Base

Learn more here!

You can identify the root cause of the problem to analyse, track, and resolve recurring incidents permanently.

You will need any of the following roles:

• problem_admin
• problem_coordinator
• problem_manager
• admin

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'.

• 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).
• Note 2: If later on, you click the 'Re-analyze' button, the problem opens for reanalysis, and the state is changed to Root Cause Analysis.

Screenshot 1: A problem manager accepting risk on a problem record

Screenshot 2: The 'problem_coordinator' role record

Learn more here!

Service Catalogue offers a few types of catalogue items.

The basic Service Catalogue item types include:

• Record producers: giving alternative ways of adding information, such as Incidents via the service catalogue.
• Order guides: to group multiple catalogue items in one request.
• Content Items: catalogue items that provide information instead of goods or services.

The total number of tasks, the order of tasks, the work described in the tasks, and the group assigned to the tasks are predefined for each catalogue item.

Learn more here!

Approvals are a critical component of the request management process. Approvals ensure that appropriate groups or individuals evaluate overall orders and individual items before fulfilment takes place. Approvals can take place at both the request level and the item level, depending on your platform configuration. Approvals can also vary by catalogue item.

There are two types of approvals:

1. Gating
2. Process

Gating occurs at the request (REQ) level. After all gating approvals are received, notifications about the request are sent out, and fulfilment task records are created.

Once a request has passed its gating approvals, any relevant workflows are initiated, including additional process approvals at the Requested Item (RITM) level.

A gating approval acts as a gate through which a request must pass before it can start.

Until all gating approvals are met, no notifications go out, no tasks get sent to technicians, and nobody starts working on the request in question.

Diagram: Example of a request that contains more than one requested item where some require approval

Learn more here!

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 is populated with the support group available for service offerings.

If you want to override the default value, you need to create new properties and provide the field in the property value that must be used to populate the Assignment group field.

Screenshot: Problem Assignment Group is getting populated based on the respective Service Offering Support Group

Learn more here!

A Catalogue Item cannot include multiple Requested For variables.

You can request a catalogue item on behalf of another user or multiple users using the Requested For variable.

Before submitting a catalogue item request, this variable helps you specify who this request can be submitted for. You should specify this information while answering catalogue item questions.

• You can only specify users from the User [sys_user] table.
• If you don't specify the default value for this variable, the currently logged-in user requesting the item is considered the default Requested For variable value.
• You can submit the request for a user based on access to a catalogue item. The 'Access Type' field of the catalogue item can be used to specify if a request can be submitted for a user who does not have access to the catalogue item.

To support submitting a request for multiple users, you can configure the 'Requested For' variable of a catalogue item to have the 'Also request for' field displayed for that item in the Service Portal.

Screenshot 1: Using the 'Requested For' variable in a sample catalogue item

Screenshot 2: Defining the 'Requested For' variable for a catalogue item

Learn more here!

First introduced: Paris release

Only an admin (admin) and a catalogue admin (catalog_admin) can create or delete a catalogue and activate or deactivate a catalogue item.

Table: Different service request roles and their access

Learn more here!

Here are the steps to take during the Resolve and Close stage in the problem management lifecycle:

• Update resolution information,
• Update or retire knowledge articles,
• Re-analyse the problem (returns to Root Cause Analysis), and
• Complete problem.

Screenshot 1: Selecting the 'Complete' UI action closes the problem and moves it to the 'Closed' state

Screenshot 2: List of Resolved problems

Screenshot 3: List of Closed problems

Learn more here!

Identify knowledge bases that are accessible to unauthenticated users based on user criteria and the system property settings.

You can use user criteria to determine access to the knowledge base for unauthenticated users.

If no user criteria are specified for the knowledge base, as an administrator, you can set the value of the glide.knowman.block_access_with_no_user_criteria system property to true.

Knowledge View Counts and flagged articles do not provide any information on who viewed or searched for the articles and whether unauthenticated users access them.

Diagram: Read access to a knowledge article flowchart

Learn more here!