Consolidated page of all release notes for Incident Management from Vancouver to Yokohama.
How to use this page
To help you prepare for your upgrade, we have combined the cross-family Incident Management release notes onto one page. Read this summary of the new features, changes, and updated information for your product from Vancouver to Yokohama.
Tip: If there were no updates for a release notes section in a certain family release, we included a short note for your reference. For example, if a product did not have any updates in Tokyo, the row says "No updates for this release."
Important information for upgrading Incident Management to Yokohama
Before you upgrade to Yokohama, review these pre- and post-upgrade tasks and complete the tasks as needed.
| Release |
Release notes |
Vancouver |
No updates for this release. |
Washington DC |
No updates for this release. |
Xanadu |
No updates for this release. |
Yokohama |
No updates for this release. |
New features
Between your current release family and Yokohama, new features were introduced for Incident Management.
| Release |
Release notes |
Vancouver |
- Enhancement to the major incident creation process
- Control when to promote an incident to a major incident or propose a major incident candidate by using the Action to take field when defining the trigger rules for a major incident. By default, the
base system activates a trigger rule that automatically promotes an incident with Priority value 1 to a major incident.
|
Washington DC |
- User role for read and write access to incident tasks
- Provide more read and write operation privileges in an incident task record to an agent with the sn_incident_task_assigned_user role. You must install and activate the ITSM Roles plugin (com.snc.itsm.roles) to use the base
system ACLs related to this role.
|
Xanadu |
No updates for this release. |
Yokohama |
- User role for service desk agents
- With the sn_service_desk_agent user role, increase the operational efficiency by streamlining the process of asking about, gathering, and verifying information, as well as delivering quick
resolutions. This role is designed for tier 1 service desk agents and is accessible when the ITSM Roles plugin (com.snc.itsm.roles) installed.
The sn_service_desk_agent role includes the following user roles:
- sn_incident_write
- sn_problem_write
- sn_change_write
- sn_request_write
- tracked_file_reader
Additionally, with the installation of the ITSM Gen AI (com.sn.itsm.gen.ai) plugin, the knowledge_user, and now_assist_panel_user roles are integrated within the sn_service_desk_agent role. The
sn_service_desk_agent role can be used starting with SOW version 6.1.
- Enhanced security model adoption for incident tables
- Help prevent unauthorized access to incident-related tables using Deny-Unless ACLs. A Deny-Unless authentication ACL restricts access for a non-authenticated user, such as a public role user. Without access, the user can't
perform any actions on incident-related tables, including reading, writing, deleting, creating, or accessing the report view.
This feature is activated automatically and applicable on the following incident-related tables:
- kb_template_incident_kcs_articl
- kb_template_incident_kcs_template
Additionally, this feature is available on the following incident-related tables of new or zBoot instances after installing the ITSM Enhanced Security Features (com.snc.itsm.enhanced_security) plugin:
- incident
- incident_task
- task_ci
- task outage
The ITSM Enhanced Security Features (com.snc.itsm.enhanced_security) plugin can be installed and activated by an admin via a support request. Existing or upgrade users must test and evaluate the results in their
non-production instance, and then install the plugin and implement the security change in their production instance. For more information, see Deny-Unless ACL.
|
Changes
Between your current release family and Yokohama, some changes were made to existing Incident Management features.
| Release |
Release notes |
Vancouver |
- Solution definition enhancements
- Solution definitions now use the Description field in addition to the Short Description field to recommend similar incidents in an Incident record. A Machine Learning (ML) model
enables the Description field in solution definitions to provide better quality results. The following solution definitions have been changed to include the Description field:
- Similar Incidents
- Similar Open Incidents
- Similar Closed Incidents
- Incident resolution behavior
- When you resolve an incident in Core UI by using the Resolve UI action or by setting the incident state to Resolved, the Resolve dialog box is displayed with resolution code and resolution notes.
|
Washington DC |
No updates for this release. |
Xanadu |
- Email notification link redirection behavior
- In email notifications, you can now decide where the links to an incident record are redirected. Instead of an incident record automatically opening in the classic UI16 interface in Incident Management, the incident record can be opened in SOW. The incident record link in an email notification opens in SOW only if the following conditions are met:
- The Redirect SOW Email notification (sow_email_notification_redirect) system property is set to true.
- The user selecting the incident record link has the sn_sow.sow_user role.
The ITSM Notifications Redirection (com.snc.itsm.notifications_redirection) plugin is installed and activated automatically to support this behavior. To ensure consistency, the email notification template is
updated to send the notification from SOW in the same format as sent from classic UI16 interface. Also, the template theme is updated to match the Next Experience theme.
|
Yokohama |
- Email redirection behavior for major incident email notification links
- In major incident email notifications, you can now decide where the links to a major incident record are redirected. Instead of a major incident record automatically opening in the classic UI16 interface in Major Incident Management, the record can be opened in SOW. The major incident record link in an email notification opens in SOW only if the following conditions are met:
- The Redirect SOW Email notification (sow_email_notification_redirect) property is set to true. Setting this property to true enables the email
redirection behavior for all tables including major incident.
- The Redirect SOW Email notification for Major Incident Management (sn_major_inc_mgmt.sow_email_notification_redirect.mim) property is set to true.
- You have the sn_sow_user role.
The ITSM Notifications Redirection (com.snc.itsm.notifications_redirection) plugin is installed and activated automatically to support this behavior.
- Email redirection behavior for incident email notification links
- In incident email notifications, you can now decide where the links to an incident record are redirected. Instead of an incident record automatically opening in the classic UI16 interface in Incident Management, the record can be opened in SOW. The incident record link in an email notification opens in SOW only if you have the sn_sow_user role and any of the following conditions are met:
- The Redirect SOW Email notification (sow_email_notification_redirect) property is set to true. Setting this property to true enables the email
redirection behavior for all tables including incident.
- The Redirect SOW Email notification for Incident Management (sow_email_notification_redirect.incident) property is set to true. You can create this
property if you want to enable or restrict the email redirection behavior specifically for the incident table. This property, if created and set, overrides the Redirect SOW Email notification
(sow_email_notification_redirect) base system property.
The ITSM Notifications Redirection (com.snc.itsm.notifications_redirection) plugin is installed and activated automatically to support this behavior. To ensure consistency, the email notification templates for
incident tasks are also updated to send the notification from Service Operations Workspace (SOW) in the same format as sent from classic UI16 interface similar to incident. Also, the template theme is updated to match the Next Experience theme.
- Incident and problem workflow changes
- When a problem is fixed and the Share fix option is triggered, the event is added to the Work notes (Private) field instead of the Additional comments (Customer
visible) field for the incident associated with the problem record.
This feature is available in the base system for the new customers. For existing or upgrade customers, admin must set the
Communicate problem workaround to incident worknotes
(com.snc.incident.communicate_prb_workaround_to_inc_worknotes) system property to true to enable the feature.
- Changes in the reopening incident behavior
- Enable the agents with incident write access, callers, requesters, or Opened by end users to reopen a resolved incident. Both the caller and the requester can view and use the
Reopen option on the incident classic UI16 form and the Portal UIs, such as Service Portal and Employee Service Center (ESC) portal.
An agent can view and use the Reopen option on the incident classic UI16 form to reopen any incident that is assigned to them or to other
agents. However, on the Portal UI, an agent can only view and use the Reopen option to reopen an incident if it’s assigned to them.
- Sorting CIs in incident forms
- The search performance of the available CIs for the Configuration item field on an incident form is enhanced to promote a clean UI and quick loading and sorting of the CIs. The search results that list
the CIs are sorted alphabetically by CI name instead of by CI class and then CI name. The ref_ac_order_by=sys_class_name attribute is removed from the default attributes on the
cmdb_ci field of the Task [task] table, which increases the performance of the field.
This change is applicable to new and existing users using the default attributes. You can use the
Override attributes option to restrict this change for any required child tables that extend to the cmdb_ci field of the Task [task] table.
|
Removed
Between your current release family and Yokohama, some Incident Management features or functionality were removed.
| Release |
Release notes |
Vancouver |
No updates for this release. |
Washington DC |
No updates for this release. |
Xanadu |
No updates for this release. |
Yokohama |
No updates for this release. |
Deprecations
Between your current release family and Yokohama, some Incident Management features or functionality were deprecated.
| Release |
Release notes |
Vancouver |
No updates for this release. |
Washington DC |
No updates for this release. |
Xanadu |
No updates for this release. |
Yokohama |
No updates for this release. |
Activation information
Review information on how to activate Incident Management.
| Release |
Release notes |
Vancouver |
Incident Management is active by default with the Incident plugin (com.snc.incident).
|
Washington DC |
Incident Management is active by default with the Incident plugin (com.snc.incident). |
Xanadu |
Incident Management is a ServiceNow AI Platform feature that is active by default. |
Yokohama |
Incident Management is a ServiceNow AI Platform feature that is active by default. |
Additional requirements
If any additional requirements were introduced or changed for Incident Management we have noted them here.
| Release |
Release notes |
Vancouver |
No updates for this release. |
Washington DC |
No updates for this release. |
Xanadu |
No updates for this release. |
Yokohama |
No updates for this release. |
Browser requirements
If any specific browser requirements were introduced or changed for Incident Management we have noted them here.
| Release |
Release notes |
Vancouver |
No updates for this release. |
Washington DC |
No updates for this release. |
Xanadu |
No updates for this release. |
Yokohama |
No updates for this release. |
Accessibility information
Review details on accessibility information for Incident Management, such as specific requirements or compliance levels.
| Release |
Release notes |
Vancouver |
No updates for this release. |
Washington DC |
No updates for this release. |
Xanadu |
No updates for this release. |
Yokohama |
No updates for this release. |
Localization information
If there are specific localization considerations for Incident Management we have noted them here.
| Release |
Release notes |
Vancouver |
No updates for this release. |
Washington DC |
No updates for this release. |
Xanadu |
No updates for this release. |
Yokohama |
No updates for this release. |
Highlight information
If there are specific highlight considerations for Incident Management we have noted them here.
| Release |
Release notes |
Vancouver |
- Improve the prediction and recommendation of similar incidents with solution definition enhancements.
- Control when to promote an incident to a major incident or propose a major incident candidate.
See Incident Management for more information.
|
Washington DC |
Manage the read and write access of agents using the sn_incident_task_assigned_user role.
See Incident Management for more information.
|
Xanadu |
Control when an incident record link in the email notifications redirects to the incident record in Service Operations Workspace (SOW).
See Incident Management for more information.
|
Yokohama |
- Increase the operational efficiency of the tier 1 service desk agents with the dedicated sn_service_desk_agent role.
- Control whether an incident or major incident record link in an email notification redirects you to the record in the classic UI16 interface or Service Operations Workspace (SOW).
- Enable agents with incident write access, callers, requesters, and Opened by end users to reopen a resolved incident from the Incident Management classic UI16 form, SOW, or Portal UIs.
- Restrict unauthorized access to incident-related tables using deny ACLs.
- Search for a configuration item (CI) in a list alphabetized by the CI name with an improved search performance.
See Incident Management for more information.
|