You can disable commenting, suggesting, rating, marking as helpful and category editing for all knowledge articles belonging to a Knowledge Base on the knowledge base form.

• If the ‘Disable commenting’ is checked at the Knowledge Base level, writing comments to an article is disabled for all articles belonging to that knowledge base.
• If ‘Disable Suggesting’ is checked at the Knowledge Base level, the ‘Flag Article’ button does not appear for any articles belonging to that knowledge base.
• If the ‘Disable rating’ is checked at the Knowledge Base level, the star rating option does not appear for any articles belonging to that knowledge base.
• If the ‘Disable Mark as helpful’ is checked at the Knowledge Base level, the ‘Mark as helpful’ option does not appear for any articles belonging to that knowledge base.

Screenshot: List of options that can be disabled on the knowledge base form

Learn more here!

User Criteria control who can read and who can contribute and are available at Knowledge Base, Knowledge Article, and Knowledge Block levels.

Here are the triggers to conflict detection in change requests:

1. Manual,
2. Insert or Update the change records, and
3. As scheduled jobs based on lead time to Planned Start.

The Conflicts tab displays a list of any conflicts identified. If a manual check needs to be run to recheck for conflicts, you click the 'Check Conflicts' button.

Learn more here!

The problem state should change to Assess when a problem manager assigns it to himself/herself and starts associating the incidents.

Learn more here!

Most Useful and Most Viewed on the Knowledge homepage are dynamically generated based on the number of times accessible articles were marked as useful and the number of times accessible articles were viewed.

Highest Rated is not an out-of-the-box list and is not available on the knowledge homepage.

Featured Content is manually set and is a static list.

Screenshot: The Most Useful and Most Viewed widgets on the homepage of the Knowledge Management Service Portal

Learn more here!

As a major incident manager, you can:

• Promote a candidate to a major incident by clicking 'Promote to Major Incident' from the context menu.
• Create a new major incident by clicking 'Create Major Incident' from the left navigation pane.
• Promote an incident to a major incident without going through the proposal process.

Major Incident Managers can demote major incidents, reject candidates and promote candidates to major incidents.

However, the Major Incident Manager role cannot manage trigger rules.

Screenshot: Creating a Major Incident trigger rule for active critical network incidents

Learn more here!

You can create a template that defines default values for forms so that users can easily create an incident. You need to have appropriate permissions before creating templates.

Users with the sn_incident_write role can create their own templates for frequently logged incidents.

• An itil user can also create a template from an incident, but since it contains the sn_incident_write role, it is not the minimum required role.
• An administrator or user with the template_editor_global role can create templates available to everyone.

Note: An administrator can enable the global option for any personal template a user creates so that all other users can access the template.

The template automatically populates fields in the incident form.

Screenshot 1: Selecting the Toggle Template Bar by clicking the more options icon to see the template bar (UI16)

Screenshot 2: Toggling the template bar on the Incident form to select an existing or create a new template (Next Experience UI)

Screenshot 3: Clicking the add icon on the template bar (UI16)

Screenshot 4: Creating a template from an existing incident record (Next Experience UI)

Learn more here!

A Release represents a planned release for a product.

The release content is defined by the features (and associated change requests) that it implements.

You can use a Product record in Release Management to store information about a product for reference purposes.

Start by defining a release for the Product and add child releases or release phases for the release. Then, scope the release by defining work artifacts for the release. Once a product is defined, you can plan and execute a release.

You can use the 'Configuration Items' reference field to link the Product with a corresponding CI in the CMDB. Each CI keeps information about how it relates to other CIs and can track any incidents, problems, or changes related to it. Specifying a CI for the Product connects information from the release process to other processes in the instance.

Learn more here!

Regardless of the item ordered, all requests for goods and services are structured similarly. When a request is submitted, a request record is created. Every request created has a REQ number.

The request record can have one or more requested items. All requested items have a RITM number. To fulfil a RITM, one or more catalogue tasks are created. Each catalogue task is identified by an SCTASK number.

The RITM for the phone continues through the approval process. If there are multiple items in the request, rejecting one RITM does not affect the fulfilment of other RITMs.

Screenshot: Request Records Hierarchy

Learn more here!

You can add knowledge articles to Service Portal case records to resolve cases.

You can use knowledge articles in Agent Workspace to deflect cases.

You can create knowledge articles using templates from a case in Agent Workspace.

You can enable customers to search for information from the knowledge base and community and find solutions to their issues.

Screenshot: Creating a new knowledge article from a case on Agent Workspace

Learn more here!