When you create a problem from an incident that is not resolved, the State field is automatically populated with the On Hold value, and the On hold reason field is automatically populated with the Awaiting problem value on the Incident form.

Screenshot: Creating a Problem from an Incident updated the State and On hold reason fields

Learn more here!

Service Catalog contains a collection of orderable products and services.

Service Portal is a customised interface used to build and submit an order.

Service Catalog Request is a collection of one or more ordered items.

Requested Items are products placed in the shopping cart.

Request management is the process for managing the request lifecycle from initial request through the fulfillment process.

Preparing the order is normally associated with the fulfillment stage in the Request Management lifecycle.

When a task is complete, the process user (Fulfiller) should update the catalogue task record with the following information:

• The configuration item that was added, modified or removed if applicable
• Work notes on what actions were taken and any challenges encountered

Learn more here!

You can automatically populate the Change Assignment group field based on the change group available for the respective configuration item (CI).

If the CI does not have any change group, then the field is populated with the change group available for service offerings.

Note: The business rule is triggered when a change request is created or updated, and when the 'Assignment group' and the 'Assigned to' fields are empty.

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: Change Assignment Group is getting populated based on the respective CI Change Group

Learn more here!

UI policies can be used to define custom process flows for tasks.

Catalogue UI policies control the behaviour of catalogue item forms when presented to your users. Catalogue UI policies can be applied to a catalogue item or a variable set.

Like UI policies, Catalog UI Policies allow variables to be set to mandatory, visible, or read-only based on defined conditions.

These policies work on variables included in catalogue item forms and variables displayed through a variables editor on the request, request item, and catalogue task forms.

Note 1: The Set visible policy does not apply to the following variable types:

• Break,
• Container Split,
• Container End.

Note 2: The Mandatory and Read Only policies do not apply to the following variable types:

• Break,
• Container Split,
• Container End,
• UI Macro,
• UI Macro with Label,
• Label, UI Page.

The priority order for UI actions types is:

• Mandatory (highest)
• Read-only/Display

Table: Catalogue UI policies and UI policy actions

Learn more here!

When you click Communicate Fix under Related Links in a Problem record, a notification is sent to the current owner (i.e. Assigned to user) of the related incidents that a fix is available.

When you communicate a fix, a notification is sent to related incidents that a fix is available. The Incident process is designed to use the fix information or to notify the user of the same.

Note: After you have completed the root cause analysis of a problem and have come up with a resolution or fix for that problem, submit change requests to get the problem fixed. Documenting and communicating fix helps users to know the solution to a problem.

Screenshot 1: The 'Communicate Fix' link on the fix-in-progress problem

Screenshot 2: Selected the 'Communicate Fix' link on the problem

Screenshot 3: The 'Fix notes' is copied to the 'Work notes' of the related incidents

Learn more here!

Major incident trigger rules are evaluated asynchronously each time an incident is created or updated, provided the following conditions are met:

• The incident record does not have the Parent Incident populated, meaning that the current incident is not a child incident.
• It is not proposed or accepted as a Major incident.
• The incident is active.

Note: The base system's major incident trigger rules are disabled by default.

The following are pre-defined trigger rules with the Major Incident Management plugin:

1. Critical Business Services Impacted
2. Number of child Incidents
3. P1 Incident
4. High severity incident

System Administrators and Incident Managers can modify and or create additional trigger rules.

Screenshot 1: List of Major Incident Trigger Rules

Screenshot 2: Example of a Major Incident Trigger Rule

Learn more here!

Use Flow Designer to build and extend workflows on a single unified platform quickly. Simplified flows for Change Management focus on optimisation and scaling.

The Change Management Change flows provide a library of reusable actions and end-to-end implementations of the base system's change models.

You can use the ServiceNow Flow Designer to create, operate, and troubleshoot flows. The Flow Designer is a single interface that provides:

• Natural language descriptions.
• Runtime information.
• Consolidated configuration.

The following change flows have been added in the Quebec release to process the Normal, Emergency, Standard, and Unauthorized change models:

• Change-Cloud Infrastructure-Authorize
• Change-Normal-Assess
• Change-Normal-Authorize
• Change-Normal-Implement
• Change-Standard
• Change-Standard-Implement
• Change-Emergency-Authorize
• Change-Emergency-Implement
• Change-Emergency-Review
• Change-Unauthorize-Authorize

Screenshot: Using Flow Designer for the actions in the Authorize state in the Emergency Change

Learn more here!

One of the benefits of driving incident categorisation by configuration item is to reduce the complexity of assignment rules by leveraging the Support group field on CI.

All other options are challenges and disadvantages.

You can use Predictive Intelligence to predict the Category for your incoming incidents.

You will need to include the 'Configuration Item' in the 'Input fields' as a parameter to help train the model.

Screenshot 1: Predicting Category for incoming incidents using the guided setup

Screenshot 2: The process of training a model based on the input parameters and the number of matching records (Output field is Category)

Learn more here!

In the Service field in a change request, you should type or select the component that appears to be affected by or causing the issue.

Once you select a value, these additional icons appear:

1. Open in Dependency Views,
2. Show other active tasks, and
3. Preview this record.

• You can click on the 'Dependency Views' icon to view the visual depiction of upstream and downstream related services and CIs along with the type of each relationship in a separate tab.
• You can click on the 'Other active tasks' icon to open the list of tasks related to this service already in progress. These include other problems, incidents, and changes.
• You can click on the 'Preview' icon to open a pop-up view of the referenced service.
• 
  

Learn more here!