様々な製品に関するアップグレード前後のタスク

リリースバージョン: Xanadu

更新日 2026年04月15日

所要時間：133分

アップグレードの準備として、さまざまなアプリケーションや機能のアップグレードおよび移行のタスクを確認します。該当する場合は、アップグレード完了前後でそれらのタスクを完了する計画を立てます。

スムーズなアップグレードのためのインスタンスの準備

アップグレード前のタスク、アップグレード、アップグレード後のタスク

Xanadu にアップグレードする前に、これらのアップグレード前後のタスクを確認し、必要に応じて完了してください。

アップグレードおよび移行のタスク

重要:

自己ホスト型のお客様のアップグレード手順の変更について詳しくは、 KB0563844 を参照してください。

製品リリースノートファミリ

AI 検索

以前のリリースから Tokyo にアップグレードすると、AI 検索は、カタログアイテム [sc_cat_item] テーブルおよびナレッジ [kb_knowledge] テーブルのインデックス付きソースからコンテンツとメタデータに自動的にインデックスを再作成します。この 1 回限りのインデックス再作成プロセスは、このリリースで検索エクスペリエンスを改善するために必要です。

以前のリリースから Tokyo にアップグレードした後に検索アプリケーション構成を表示または編集すると、1 つ以上のインデックス付きソースを再インデックス付けするように指示する警告メッセージが表示される場合があります。このインデックス再作成プロセス (リストされているインデックス付きソースごとに 1 回限りのプロセス) は、検索ベースのオートコンプリート候補を正しく入力するために必要です。

以前のリリースから Tokyo にアップグレードすると、検索結果のデフォルトの関連性スコアが変更される場合があります。以前のリリースでトレーニングされた関連性モデルは、引き続き同じ結果の順序を生成します。複数のリリース前にトレーニングされたモデルは、デフォルトの関連性モデルに戻る可能性があります。

AI 検索 report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、 Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。

Tokyo

アドミンセンター

アドミンセンターアプリケーションの最新バージョンは、ServiceNow Store で入手できます。

Tokyo

アプリケーションポートフォリオ管理

アプリケーションポートフォリオ管理 report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、 Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。

Tokyo

アセスメントとサーベイ

以前のリリースから Tokyo にアップグレードすると、サービスポータルと Now Mobile アプリでアセスメントとサーベイがデフォルトでアクティブ化されます。

Tokyo

認証

認証 report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。

Tokyo

自動テストフレームワーク (ATF)

Now Platform® で提供されているクイックスタートテストをコピーしカスタマイズして、構成変更後もインスタンスが動作することを検証します。たとえば、アップグレードを適用するか、アプリケーションを開発する場合です。

カスタマイズを行っていないベースシステム上で、アプリケーションまたは機能プラグインが提供するデフォルトのデモデータを使用してテストを実行した場合にのみ、テストで合格の結果を生成できます。インスタンス固有のデータにクイックスタートテストを適用するには、クイックスタートテストをコピーしてカスタムデータを追加します。詳しくは、「Available quick start tests by application or feature (アプリケーションおよび機能別に利用可能なクイックスタートテスト)」を参照してください。

Tokyo

Cloud Provisioning and Governance

Cloud Provisioning and Governance report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。

Tokyo

コンフィギュレーションコンプライアンス

コンフィギュレーションコンプライアンスアプリケーションのモデル変更により、アップグレードには以前よりかなり長い時間がかかる場合があります。詳しくは、KB0856498 を参照してください。
以前にアプリケーションを ServiceNow Store からダウンロードしていて新バージョンが利用可能な場合、 Now Platform インスタンスで更新できます。
コンフィギュレーションコンプライアンスアプリケーションのリリース済みバージョンと、Tokyo と互換性のあるサードパーティアプリケーションや ServiceNow アプリケーションについて詳しくは、HI ナレッジベース記事「Vulnerability Response Compatibility Matrix and Release Schema Changes (脆弱性対応互換性マトリックスおよびリリーススキーマの変更点) [KB0856498]」を参照してください。
脆弱性対応とコンフィギュレーションコンプライアンスでサポートされているサードパーティアプリケーションの更新については、「脆弱性対応統合リリースノート」を参照してください。

表 : 2. コンフィギュレーションコンプライアンスの Tokyo へのアップグレード情報
バージョン	アップグレードの説明
14.3	ServiceNow Store で Tokyo の認定済みです。詳細については、以下の「Tokyo リリースの新機能」セクションを参照してください。

Tokyo

対話型インターフェースのホーム

対話型インターフェースのホームは Tokyo リリースに含まれていますので、既存のお客様はインストールする必要はありません。ただし、ServiceNow Store からアプリとしても入手できます。その場合は、後続の更新はそこからインストールする必要があります。

Tokyo

Core Now Platform

ログ保護をオプトインするには、プラットフォームで特定のシステムログテーブルの更新および削除操作を制限できるようにする Protected Tables プラグイン (com.glide.protected_tables) をインストールします。アドミニストレーターは、[ログ保護管理] パネルで各テーブルのログテーブル保護ルールをカスタマイズできます。

Core Now Platform report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。

Tokyo

カスタマーサービス管理 (CSM)

カスタマーサービス管理 (CSM) report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。

Tokyo

従業員ジャーニー管理

HR サービスデリバリ (HRSD) report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。

Tokyo

暗号化キー管理

暗号化コンテキストは、San Diego リリース以降へのアップグレード時に、列レベル暗号化フィールド暗号化モジュールおよび対応するモジュールアクセスポリシーに自動的に変換されます。この機能拡張について説明するガイド付きツアーをダッシュボードから利用できます。

暗号化キー管理 report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。

Tokyo

フローデザイナー

フローデザイナー report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。

San Diego およびそれ以前のリリースからアップグレードしたインスタンスが、フローとアクションに対する制限付き呼び出し元アクセス権限要求を生成できるようにすることができます。フローとアクションのアクセス権限を有効にする方法の詳細については、「Upgrade restricted caller access privileges for flows and actions (フローとアクションに対する制限付き呼び出し元アクセス権限のアップグレード)」を参照してください。

警告:

フローとアクションを追跡するように制限付きの申請者アクセス特権をアップグレードすると、以前はスクリプトインクルードやビジネスルールからのクロススコープアクセスを追跡していたインスタンスで、サービスが中断される可能性があります。アップグレード後は、制限付きリソースへのアクセスを試みるすべてのフローとアクションの実行がブロックされ、代わりにそのフローやアクション独自の制限付きの申請者アクセス特権に対する承認要求が生成されます。クロススコープのフローおよびアクションを実行するには、アクセス権限要求を誰かが承認する必要があります。スクリプトの呼び出しを使用してフローとアクションの間接的な追跡を既に許可しているお客様は、このタスクをスキップして、引き続きスクリプトからフローとアクションを呼び出すことができます。既存のアクセス権限を新しいフローおよびフローアクションのソースタイプに置き換えたいお客様は、新しいアクセス権限要求を生成および承認するための機能停止のスケジュールを設定することができます。

Tokyo

ガバナンス、リスク、コンプライアンス

ガバナンス、リスク、コンプライアンスバージョン 14.0 以降、ビジネスユーザー (sn_grc.business_user) ロールは GRC リーダー (sn_grc.reader) ロールから削除され、GRC ユーザー (sn_grc.user) ロールに追加されます。詳細については、KB1123608 を参照してください。

Tokyo

HR サービスデリバリ用ケースとナレッジ管理

Tokyo

ヘルスログアナリティクス

Health Log Analytic のバージョンが 2022 年 2 月より前の場合は、Now Support または ServiceNow 営業担当者に連絡して、ヘルスログアナリティクスアプリケーションコアコンポーネントのアップグレードを要求してください。

Tokyo

ITOM ヴィジビリティ

ITOM ヴィジビリティ report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。

Tokyo にアップグレードすると、検出されたすべてのインフラストラクチャ CI のインストールステータスが自動的に「インストール済み」(「1」) に設定されます。組織でインストールステータスを使用している場合は、本番インスタンスをアップグレードする前に、テストインスタンスで Tokyo をテストしてください。

CSDM ライフサイクル状況を使用して、CI のライフサイクルステージとステージステータスを追跡します。詳細については、[Placeholder link text to key bundle-rn.bundle-platcap.csdm-life-cycle-standard-values (キー bundle-rn.bundle-platcap.csdm-life-cycle-standard-values へのプレースホルダーリンクテキスト)] を参照してください。

Tokyo へのアップグレード後にインストールステータスに関連する問題を解決するには、KB1213467 を参照してください。

Tokyo

インポートとエクスポート

インポートとエクスポート report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。

Tokyo

インシデント管理

インシデント管理 report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。

Tokyo

インスタンスデータレプリケーション (IDR)

インスタンスデータレプリケーション (IDR) report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。

Tokyo

Instance Scan

Instance Scan report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。

Tokyo

統合ハブ

統合ハブ report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。

Tokyo

Intelligent Service Delivery

Tokyo

ナレッジ管理

ナレッジ管理 report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。
Tokyo リリース以降、アップグレードされたバージョンの Angular JS 1.5.11 がベースシステムで利用可能になりました。

Tokyo

法務サービスデリバリ

法務サービスデリバリを Tokyo にアップグレードする前に、glide.rollback.blacklist.TableParentChange.change システムプロパティの値を false に設定する必要があります。このプロパティがシステムプロパティ [sys_properties] テーブルに存在しない場合は、プロパティを追加し、その値を false に設定します。

アップグレード後、法務要求管理、法務デジタルフォレンジック、Legal Simple Contracts の各アプリケーションでインストールされた一部のテーブルは、アプリケーションファイル [sys_metadata] テーブルを拡張して、実務エリア、問診票フォーム、契約構成、フォレンジック構成を更新セットにシームレスに移行できるようにします。

システムプロパティ値を更新せずに Tokyo バージョンにアップグレードすると、テーブルはアプリケーションファイルテーブルを拡張しません。テーブルの変更を手動で更新するには、Now Support ナレッジベース記事「Manual upgrade steps for reparenting table changes in Tokyo (Tokyo でテーブル変更の親を再指定する手動アップグレード手順) [KB1163388]」を参照してください。

Tokyo

MID サーバー

最新の MID サーバーシステム要件については、「MID Server system requirements (MID サーバーシステム要件)」を参照してください。次の Java Runtime Environment (JRE) バージョンがサポートされています。

JRE11：バージョン 11.0.15 以降
JRE8：バージョン 1.8.0_275 以降

独自の JRE をインストールしている場合、アップグレードプロセスは次のアクションを実行して、MID サーバーがサポートされている JRE を使用するようにします。

アップグレード時に MID サーバーがサポートされていないバージョンの JRE を使用している場合、アップグレードプロセスはその JRE を MID サーバーインストーラーにバンドルされている OpenJDK に置き換えます。
サポートされている JRE が MID サーバーホストで実行されている場合、アップグレードされた MID サーバーはそのバージョンを使用します。

自動アップグレードを行なうには、すべての MID サーバーホストマシンが install.service-now.com のダウンロードサイトにアクセスする必要があります。詳細については、「How the System Manages MID Server Upgrades (システムが MID サーバーアップグレードを管理する方法)」をご確認ください。

1 つの実行可能ファイルパスにつき、 Windows MID サーバーサービスは 1 つのみ許可されます。アップグレードした Windows MID サーバーに同じインストールフォルダーを指しているサービスが複数ある場合は起動できません。詳しくは『MID Server fails to start (MID サーバーが起動しない)』を参照してください。

MID サーバーのアップグレードについて詳しくは次のトピックを参照してください。

MID サーバーのアップグレード前のチェック：実際にアップグレードを行なう前に、システムでの MID サーバーのアップグレード機能を AutoUpgrade モニターでテストする方法を説明しています。
手動での MID サーバーのアップグレード：MID サーバーを手動でアップグレードする方法について説明しています。

Tokyo

モバイル

ServiceNow クラシックモバイルプアプリから ServiceNow モバイルプラットフォームに移行すると、迅速な開発、オフライン機能、ネイティブモバイルデバイス機能との統合などの機能が活用できます。ServiceNow モバイルプラットフォームへの移行の詳細については、「Migrate from the ServiceNow Classic mobile app to the ServiceNow Mobile Platform (ServiceNow 従来版モバイルアプリから ServiceNow モバイルプラットフォームへの移行)」を参照してください。

ServiceNow モバイルプラットフォーム report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。

Tokyo

オペレーショナルテクノロジーインシデント管理 v2

以前のリリースでオペレーショナルテクノロジーインシデント管理を使用している場合、以前に OT インシデントユーザー (ot_incident_user) ロールが割り当てられていたユーザーにオペレーショナルテクノロジーインシデント管理 v2 ロールを新たに割り当てる必要があります。詳細については、「Assign new Operational Technology Incident Management roles (新しいオペレーショナルテクノロジーインシデント管理ロールの割り当て」を参照してください。

Tokyo

パスワードリセット

パスワードリセット report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。

Tokyo

プロジェクトポートフォリオ管理

プロジェクトポートフォリオ管理 report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。

PPM のシナリオ計画をバージョン 2.3.0 以降にアップグレードする場合は、統合を機能させるには、従来の投資枠管理アプリケーションを ServiceNow Store にアップグレードする必要があります。従来の投資枠管理から ServiceNow Store アプリケーションへのアップグレード手順の詳細については、「Upgrade Instructions (アップグレード手順)」を参照してください。

Tokyo

サービスブリッジ (テクノロジー)

サービスブリッジアプリケーションの Tokyo バージョンにアップグレードするには、 Now Support ナレッジベースの記事「Service Bridge- Upgrade steps for San Diego store release to Tokyo store release (サービスブリッジ - San Diego ストアリリースから Tokyo ストアリリースへのアップグレード手順) [KB1120583]」を参照してください。

Tokyo

サービスブリッジ (電気通信)

Tokyo

Service Operations Workspace for ITSM

次のアプリケーションに互換性のあるアップグレードバージョンが存在することを確認します。

サービスオペレーションワークスペース ITSM Applications アプリケーション (sn_sow_itsm_cont)
サービスオペレーションワークスペース ITOM アプリケーション (sn_sow_itom_cont)

表 : 3. 互換性のある SOW バージョン
SOW-ITSM (sn_sow_itsm_cont)	SOW-ITOM (sn_sow_itom_cont)
1.1.x	21.0.y
1.2.x	21.1.y
1.3.x	21.2.y、21.5.y、および 21.6.y
2.0.x	22.0.y
2.1.x	22.1.y および 22.y.y

ここで、x はサービスオペレーションワークスペース ITSM Applications アプリケーション (sn_sow_itsm_cont) のサブバージョンで、y はサービスオペレーションワークスペース ITOM アプリケーション (sn_sow_itom_cont) のサブバージョンです。

Tokyo

サービスポータル

アップグレードで有効になる Report_view ACL

サービスポータル report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。

Report_view ACL は、以前は新しい (zBoot) インスタンスで有効でした。

注:

サービスポータル report_view アクセス制御リスト (ACL) のリストについては、[すべて] > [システムセキュリティ] > [アクセス制御 (ACL)] に移動し、条件ビルダーを使用して [オペレーション] [is] [report_view] AND [Package] [contains][is not] [サービスポータル - Standard Ticket] のフィルターを追加します。

デフォルトで有効になるユーザーエクスペリエンスアナリティクスのトラッキング

サービスポータルアナリティクスプラグイン (com.glide.service-portal.analytics) はデフォルトでアクティブ化されており、ポータルのユーザーエクスペリエンスアナリティクスのトラッキングはデフォルトでオンになっています。

以前に一部のポータルのみでユーザーエクスペリエンスアナリティクスのトラッキングを有効にしていたアップグレードのお客様の場合、ポータルのトラッキング設定はアップグレード後も変更されません。

TinyMCE 5 のアップグレード

TinyMCE HTML エディターがバージョン 5.10.2 にアップグレードされました。サービスポータルで Angular プロバイダーを使用して TinyMCE 実装をカスタマイズしている場合は、カスタマイズされたバージョンのアップグレードについて、「Changes in TinyMCE 5 (TinyMCE 5 での変更点)」を参照してください。

Tokyo

ソフトウェア資産管理

Software Asset Management Foundation プラグイン (com.snc.sams) のアップグレードについて詳しくは、「Revert Software Asset Management Customizations (ソフトウェア資産管理のカスタマイズを元に戻す)」を参照してください。

Tokyo

サブスクリプション管理

サブスクリプション管理 report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。

Tokyo

アップグレードセンター

アップグレードセンター report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。

Tokyo

ベンダー管理ワークスペース

ベンダー管理ワークスペース report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。

Tokyo

仮想エージェント

新しいポータブル仮想エージェント Web クライアントは、Seismic コンポーネントで、サードパーティの Web サイトへ簡単に仮想エージェントを追加できます。サードパーティの Web ページに仮想エージェントを埋め込む従来の方法は引き続き機能します。
以前のリリースでは、仮想エージェントデザイナーのトピックブロックとカスタムコントロールはグローバルスコープで公開されていました。このリリースでは、トピックブロックとカスタムコントロールが呼び出し元トピックのスコープに含まれるようになりました。

Tokyo

ビジュアルタスクボード

ビジュアルタスクボード report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。

Tokyo

脆弱性対応統合

Vulnerability Response アプリケーションのリリース済みバージョンと、Tokyo と互換性のあるサードパーティアプリケーションや ServiceNow アプリケーションについて詳しくは、HI ナレッジベース記事「Vulnerability Response Compatibility Matrix and Release Schema Changes (脆弱性対応互換性マトリックスおよびリリーススキーマの変更点) [KB0856498]」を参照してください。
脆弱性対応の新機能の詳細については、「脆弱性対応リリースノート」を参照してください。

Tokyo

脆弱性対応

脆弱性対応アプリケーションのデータモデル変更により、アップグレードには以前よりかなり長い時間がかかる場合があります。詳しくは、KB0856498 を参照してください。

新しいバージョンへのアップグレード中は、アップグレード元のデータとバージョンに基づいてアップグレード時間が長くなる場合があります。これは、アップグレード中に追加されたスキーマの変更が原因です。詳しくは、KB0856498 を参照してください。

脆弱性対応アプリケーションを古いバージョンからバージョン 15.x にアップグレードすると、ベースシステムのデフォルトの修復タスクルールが非アクティブ化されます。詳細については、「Vulnerability Response Workspaces and updates to remediation task and remediation task rules (脆弱性対応ワークスペースおよび、修復タスクと修復タスクルールの更新)」を参照してください。

脆弱性対応 report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。

新しいバージョンの脆弱性対応アプリケーションにアップグレードすると、新しいバージョンがインスタンスで利用可能になり、インストールの準備が整います。脆弱性対応の更新は ServiceNow® Store で入手できます。
脆弱性対応アプリケーションのリリース済みバージョン、Tokyo との互換性、スキーマ変更について詳しくは、HI ナレッジベース記事「Vulnerability Response Compatibility Matrix and Release Schema Changes (脆弱性対応互換性マトリックスおよびリリーススキーマの変更点) [KB0856498]」を参照してください。

Rome で Vulnerability Response をバージョン 18.0 にアップグレードすると、脆弱性マネージャーのワークスペースはサポートされなくなります。

Tokyo

ITSM のワークフォース最適化

予測方法の改善：Demand Forecast では、改善した予測方法を使用してデータを予測します。インジケータースコアを予測するための単純な手法を線形回帰手法にアップグレードしました。以前の単純な手法では、最新のシーズンの最初と最後のスコアのみを使用しましたが、アップグレードした手法では、評価期間中に利用可能なすべてのスコアを使用します。さらに、従来の線形メソッドとドリフトメソッドを単一の線形メソッドに置き換え、95% 予測間隔の計算を改善しました。アップグレードすると、Demand Forecast で使用する予測アルゴリズムが次のように更新されます。

「単純な季節トレンド分析」アルゴリズムの名前が「季節 (Seasonal)」に変更されます。
「単純な季節トレンド分析ドリフト」アルゴリズムの名前が「季節トレンド (Seasonal Trend)」に変更されます。
ドリフトアルゴリズムが削除されます。

スケジュール計画とシフト計画のテキストインデックス作成の有効化：ITSM のワークフォース最適化バージョン 1.1.1 にアップグレードする場合は、次のテーブルのテキストインデックス作成を有効にする必要があります。

スケジュール [sn_shift_planning_schedule_plan]
シフト計画 [sn_shift_planning_shift_plan]
シフト [cmn_rota]

アップグレード後にテキストインデックス作成を実行しないと、スケジュール計画とシフト計画をキーワードで検索できません。スケジュール計画とシフト計画の名前でのみ検索できます。

ITSM のワークフォース最適化レポートビュー ACL： report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。

ラーニングのコーチング：ITSM のワークフォース最適化 Tokyo リリースにアップグレードすると、自動的に次の更新が行われます。

「学習カタログ」の名前が「学習ライブラリ」に変更されます。学習カタログ内のすべてのコースが学習ライブラリに移動されます。
マネージャーは、コースアイテムまたはラーニングパスを作成するときに、そのコースまたはパスをコースカタログに関連付ける必要があります。各カタログに適用されるセキュリティ上の制約に応じて、ユーザーはカタログ内のコースまたはパスにアクセスできます。
注:
既存のコースはすべてデフォルトのコースカタログに移行されます。

ServiceNow ストアから ITSM Shift Planning Host v 5.3.0 アプリケーションにアップグレードした後：

エージェントがシフトにサインアップできるようにするには、sn_shift_planning.enable_agent_signup プロパティを true に設定する必要があります。
スケジュールのフィルターに対する次のラベル変更が自動的に行われます。
- 「ステータス」は、「スケジュール計画ステータス」に名前が変わります。
- 「日付」は、「スケジュール計画日付」に名前が変わります。

Tokyo

AI 検索

以前のリリースから Utah にアップグレード後に、タスク [task] テーブルとその子テーブルからレコードにインデックス付けすると、AI 検索が新しい自動言語検出機能を適用します。Utah にアップグレードする前にインデックス付けをしたタスクレコードに自動言語検出を適用するには、それらのレコードを手動で再インデックス付けする必要があります。

同様に、以前のリリースから Utah にアップグレードした後で、中国語テキストまたは日本語テキストの領域を持つレコードまたはドキュメントにインデックス付けをすると、AI 検索は中国語と日本語の新しいテキスト領域検出機能を自動的に適用します。Utah にアップグレードする前に、インデックス付けしたレコードやドキュメントにテキスト領域検出を適用するには、それらのレコードやドキュメントを手動で再インデックス付けする必要があります。

Utah の新しいインスタンスではネクストエクスペリエンス向け AI 検索アプリケーションは自動的に有効になります。以前のリリースから Utah にアップグレードした場合、ネクストエクスペリエンス向け AI 検索は手動で設定および有効化できます。アプリケーションに関する詳細については、「ネクストエクスペリエンス向け AI 検索」を参照してください。

Utah

エージェントチャットおよびサイドバー

対話型インターフェースコンソールは Utah リリースに含まれているため、既存のお客様はこれをインストールする必要はありません。ServiceNow Store からアプリとしてインストールした場合は、後続の更新はそこからインストールする必要があります。

Utah

アセスメントとサーベイ

Utah リリースでは、アセスメントカードとサーベイカードのボタンをすべて削除しました。自動テストフレームワーク (ATF) テストを正常に実行するには、「[サーベイを実施] ボタンをクリックする」ステップを、このステップを含むすべてのテストで「サーベイカードをクリックする」ステップに置き換える必要があります。

Utah

Cloud Provisioning and Governance

Cloud Provisioning and Governance を Utah リリースにアップグレードした後、クラウドイベント [sn_cmp_cloud_event] テーブルの指定された列からデータベースインデックスを作成します。データベースインデックスは、インスタンスの Amazon Web Services (AWS) イベント処理パフォーマンスを向上するのに役立ちます。 Utah リリースで Cloud Provisioning and Governance の使用を開始している場合、アプリケーションのインストール時にデータベースインデックスが自動的に作成されます。詳細については、「Improve AWS cloud event processing performance (AWS クラウドイベント処理パフォーマンスの改善)」を参照してください。

Utah

コンフィギュレーションコンプライアンス

コンフィギュレーションコンプライアンスアプリケーションのデータモデル変更により、アップグレードには以前よりかなり長い時間がかかる場合があります。詳しくは、KB0856498 を参照してください。
以前にアプリケーションを ServiceNow Store からダウンロードしていて新バージョンが利用可能な場合、Now Platform インスタンスで更新できます。
コンフィギュレーションコンプライアンスアプリケーションのリリース済みバージョンと、Utah と互換性のあるサードパーティアプリケーションや ServiceNow アプリケーションについて詳しくは、HI ナレッジベース記事「Vulnerability Response Compatibility Matrix and Release Schema Changes (脆弱性対応互換性マトリックスおよびリリーススキーマの変更点) [KB0856498]」を参照してください。
脆弱性対応とコンフィギュレーションコンプライアンスでサポートされているサードパーティアプリケーションの更新については、「脆弱性対応統合リリースノート」を参照してください。

表 : 4. コンフィギュレーションコンプライアンスの Utah へのアップグレード情報
バージョン	アップグレードの説明
14.7	ServiceNow ストアで Utah の認定済みです。詳細については、以下の「Utah リリースの新機能」セクションを参照してください。

Utah

カスタマーサービス管理 (CSM)

ケースタスクの拡張により、ケースタスクレコードに複数のフィールドが追加されます。Utah リリースにアップグレードすると、顧客はスクリプトを実行してアクティブなケースタスクのこれらのフィールドに入力できます。詳細については、「Cases and case tasks (ケースとケースタスク)」を参照してください。

Utah

暗号化キー管理

暗号化コンテキストは、San Diego リリース以降へのアップグレード時に、列レベル暗号化フィールド暗号化モジュールと対応するモジュールアクセスポリシーに自動的に変換されます。この機能拡張について説明するガイド付きツアーをダッシュボードから利用できます。

暗号化キー管理 report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、Utah リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。

Utah

ハードウェア資産管理 7.0.0

既存のカスタマイズの構成を変更して、標準レコードページテンプレートと互換性を持たせる必要があります。標準レコードページテンプレートおよび構成変更の詳細については、Now Support ナレッジベースの記事「Work Instruction | How to Migrate existing Record Pages to Standard Record Pages (操作手順｜既存のレコードページの標準レコードページへの移行) [KB1224040]」を参照してください。

Utah

ヘルスログアナリティクス

Utah

ID と認証

認証 report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、Utah リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。

Utah

産業用プロセスマネージャー

Manufacturing Process Manager に同梱されている ISA サービスグラフコネクタを使用し、産業用プロセスマネージャーにアップグレードする場合は、新しい ISA 設備階層モデルエンティティに一意の名前フィールドがあることを確認してください。

Utah

インスタンスデータレプリケーション (IDR)

レプリケーションセットを V2 にアップグレードして Hermes Messaging Service を使用すると (IDR) のパフォーマンスと処理効率を向上できます。詳細については、「Upgrading legacy replication set to V2 in インスタンスデータレプリケーション (IDR) (インスタンスデータレプリケーション (IDR) の V2 への従来のレプリケーションセットのアップグレード」を参照してください。

Utah

MID サーバー

最新の MID サーバーシステム要件については、「MID Server system requirements (MID サーバーシステム要件)」を参照してください。サポートされている Java Runtime Environment (JRE) の最低バージョンは 11.0.9 で推奨バージョンは 11.0.16 です。

アップグレードの際に MID サーバーがサポートされていないバージョンの JRE を使用している場合、アップグレードプロセスで JRE の最低バージョンと推奨バージョンを示す警告メッセージが表示されます。
サポートされている JRE が MID サーバーホストで実行されている場合、アップグレードされた MID サーバーはそのバージョンを使用します。

MID サーバーのアップグレードについて詳しくは次のトピックを参照してください。

MID サーバーのアップグレード前のチェック：実際にアップグレードを行なう前に、システムでの MID サーバーのアップグレード機能を AutoUpgrade モニターでテストする方法を説明しています。
手動での MID サーバーのアップグレード：MID サーバーを手動でアップグレードする方法について説明しています。

Utah

Manager Hub

Xanadu リリースにアップグレードする場合は、従業員センターの [To Do 構成] フォームでマネージャーの To Do マッピング用に作成された追加条件を、マネージャーハブの To Do マッピングモジュールで再度作成する必要があります。

Utah

オペレーショナルテクノロジーインシデント管理 v2

Utah

プラットフォームセキュリティ

データプライバシー機能を使うには Vault エンタイトルメントを取得します。この機能の詳細については、「ServiceNow Vault」を参照してください。

Utah

ポートフォリオ計画

v6.0.1 以降、アラインメントプランナーワークスペースは SPM 標準ライセンスのポートフォリオ計画に名前が変更されます。ServiceNow インスタンスでのアプリケーション名がポートフォリオ計画と表示され、ワークスペースモジュール名はポートフォリオ計画ワークスペースと表示されます。
古いバージョンからポートフォリオ計画 v6.1.1 以降にアップグレードする場合は、roadmap_editor ロールが使用されなくなるため、roadmap_editor ロールから milestone_editor ロールを削除する修正スクリプトが実行されます。この場合、ServiceNow インスタンスに roadmap_editor ロールを持つ多数のユーザーがいると、アップグレードが完了するまでに時間がかかることがあります。詳細については、KB1443618 を参照してください。

Utah

公共機関デジタルサービス

アップグレード後、CSM 構成可能ワークスペースの特定の公共部門メニューとメニューアイテムが元の CSM ラベル名に戻ります。公共部門用のこれらのアイテムに再レベル付けするには、顧客およびサービス組織の UX リストカテゴリを更新します。詳細については、「Relabel items for public sector use after upgrade (アップグレード後に公共部門用のアイテムのラベルを変更する)」を参照してください。

Utah

ロボティックプロセスオートメーション (RPA) ハブ

現在インストール済みの Microsoft Software Installers (MSI) (RPA デスクトップデザインスタジオ、アテンド型ロボット、無人ロボット) は、RPA アプリケーションをダウンロードして必ずアップグレードしてください。詳細については、「Download the RPA applications from RPA Hub (RPA ハブからの RPA アプリケーションのダウンロード)」を参照してください。

アプリケーションファイルテーブル内のレコード数に応じて、RPA Hub アプリケーションの Tokyo から Utah へのアップグレードに遅延が生じる可能性があります。

RPA Hub を Utah にアップグレードする前に、glide.rollback.blacklist.TableParentChange.change システムプロパティの値を false に設定する必要があります。このプロパティがシステムプロパティ [sys_properties] テーブルに存在しない場合は、プロパティを追加し、その値を false に設定します。

Utah にアップグレード後、ボットプロセス定義が新しい構造のボットプロセス構成に変わります。ただし、ボットプロセス構成がボットプロセスを完全に置き換えるわけではありません。ほとんどのフィールドがボットプロセスからボットプロセス構成に移動されます。

システムプロパティ値を更新せずに Utah バージョンにアップグレードすると、テーブルは [アプリケーションファイル] テーブルを拡張しません。テーブルの変更を手動で更新するには、Now Support ナレッジベースの記事「Restructuring RPA Hub tables to sys_metadata in Utah (Utah の sys_metadata への RPA Hub テーブルの再ビルド)」を参照してください。

Utah

Service Operations Workspace for ITSM

次のアプリケーションに互換性のあるアップグレードバージョンが存在することを確認します。

サービスオペレーションワークスペース ITSM Applications アプリケーション (sn_sow_itsm_cont)
サービスオペレーションワークスペース ITOM アプリケーション (sn_sow_itom_cont)

表 : 5. 互換性のある SOW バージョン
SOW-ITSM (sn_sow_itsm_cont)	SOW-ITOM (sn_sow_itom_cont)
1.1.x	21.0.y
1.2.x	21.1.y
1.3.x	21.2.y、21.5.y、および 21.6.y
2.0.x	22.0.y
2.1.x	22.1.y および 22.y.y

Utah

サービスポータル

アップグレード後に、テーブル入力パラメーターを受け入れる公開ウィジェットのデータにゲストユーザーがアクセスできるテーブルを指定する必要があります。デフォルトでは、Utah パッチ 10 リリースでは、テーブル入力パラメーターを受け入れる公開ウィジェットは、ゲストユーザーのどのテーブルからもデータにアクセスして返すことができません。アップグレード前に glide.service_portal.widget.table_allow_list または glide.service_portal.widget.allow_list システムプロパティを追加した場合、これらのプロパティの値は、Utah パッチ 10 リリース以降にアップグレードした後にウィジェットの公開テーブル許可リストに移行されます。詳細については、「ウィジェットセキュリティの構成」を参照してください。

さらに、フィールドレベルの読み取り ACL は、デフォルトで簡易リストウィジェットインスタンスのフィルター条件に適用されます。新しいシステムプロパティ glide.service_portal.enable_acls_for_encoded_query_in_list は、簡易リストウィジェットインスタンスに対して [フィルタークエリ用語でフィールドレベルの読み取り ACL を適用する (Enforce field-level Read ACLs on Filter query terms)] オプションが選択されているかどうかに関係なく、これらの ACL を適用します。[フィルタークエリ用語でフィールドレベルの読み取り ACL を適用する (Enforce field-level Read ACLs on Filter query terms )] オプションを使用するには、glide.service_portal.enable_acls_for_encoded_query_in_list の値を false に変更します。詳細については、「簡易リストウィジェット」を参照してください。

Utah

サービスポートフォリオ管理

可用性の結果の表示は Tokyo リリースで導入されましたが後続のリリースにも適用されます。アップグレードすると、データ負荷が高いと判断されたお客様の場合、システムが長時間実行型のバックグラウンドジョブを開始し、長い時間継続する場合があります。詳しくは「KB1123644」を参照してください。

Utah

ソフトウェア資産管理

Utah にアップグレードすると、ソフトウェア保証の対象であり汎用バージョンのソフトウェアモデルに関連付けられている既存の無期限ライセンスエンタイトルメントが変更されます。ソフトウェア資産管理は、これらのエンタイトルメントをバージョン固有のソフトウェアモデルに自動的に変換します。これらの変更は、Microsoft のライセンス条項に準拠し、Microsoft 製品のすべてのバージョンにソフトウェアアシュアランス特典を適用する潜在的なリスクを軽減するために行われます。詳細については、「ソフトウェアライセンスのメンテナンス」を参照してください。

Utah

戦略的計画

v2.0.1 以降、アラインメントプランナーワークスペースは SPM Pro ライセンスの Strategic Planning に名前が変更されます。ServiceNow インスタンスでのアプリケーション名が戦略的計画と表示され、ワークスペースモジュール名は戦略的計画ワークスペースと表示されます。
Strategic Planning アプリケーションをインストールすると、[目標] フォーム上の [会社]、[事業部門]、[部門]、[ポートフォリオ] の各既存フィールドが、[アサインされたエンティティタイプ] と [アサインされたエンティティ] の 2 つのフィールドに統合され、既存のフィールドの値に基づいて自動的に入力されます。
[事業部門]、[部門]、[会社]、または [ポートフォリオ] 以外のレンズエンティティ付き m2m 関係を作成した場合は、アサインされたエンティティの目標関係を移行するスケジュールジョブを実行して、目標関係 [sn_gf_goal_m2m_relationship] テーブルのデータに基づき、[目標] フォームの [アサインされたエンティティタイプ] および [アサインされたエンティティ] フィールドに入力します。
古いバージョンからポートフォリオ計画立案 v2.1.0 以降にアップグレードする場合は、roadmap_editor ロールが使用されなくなるため、roadmap_editor ロールから milestone_editor ロールを削除する修正スクリプトが実行されます。この場合、ServiceNow インスタンスに roadmap_editor ロールを持つ多数のユーザーがいると、アップグレードが完了するまでに時間がかかることがあります。詳細については、KB1443618 を参照してください。

Utah

サプライヤーライフサイクルオペレーション

Utah リリースで、既存のすべてのテーブルの名前が変更されました。名前の変更の一環として、既存のテーブルの新しい名前に含まれる「supplier」という単語がすべて「slm」に変更されました。たとえば、サプライヤーケース [sn_supplier_case] はサプライヤーケース (sn_slm_case) に、サプライヤータスク [sn_supplier_task] はサプライヤータスク (sn_slm_task) に変更されました。Tokyo リリースから Utah リリースにアップグレードする場合は、修正スクリプトを実行して既存のテーブルをサプライヤー共通アーキテクチャに移行してください。詳細については、「修正スクリプトによる既存テーブルのサプライヤー共通アーキテクチャへの移行」を参照してください。

Utah

アップグレードセンター

アップグレードセンター report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、Utah リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。

Utah

脆弱性対応統合

脆弱性対応アプリケーションのリリース済みバージョンと、Utah と互換性のあるサードパーティアプリケーションや ServiceNow アプリケーションについて詳しくは、HI ナレッジベース記事「Vulnerability Response Compatibility Matrix and Release Schema Changes (脆弱性対応互換性マトリックスおよびリリーススキーマの変更点) [KB0856498]」を参照してください。
脆弱性対応の新機能の詳細については、「脆弱性対応リリースノート」を参照してください。

Utah

脆弱性対応

新しいバージョンへのアップグレード中は、アップグレード元のデータとバージョンに基づいてアップグレード時間が長くなる場合があります。この問題は、アップグレード中に追加されたスキーマの変更が原因です。詳しくは、KB0856498 を参照してください。

Rome で脆弱性対応をバージョン 18.0 にアップグレードすると、脆弱性マネージャーのワークスペースはサポートされなくなります。

Utah

AI 検索

以前のリリースから Vancouver にアップグレードすると、AI 検索は非タスクテーブルのインデックスを自動的に再作成して、添付ファイルの検索結果をその親レコードとともに表示できるようにしますが、タスク [task] テーブルとその子テーブルのインデックスは自動的に再作成しません。タスクレコードの添付ファイルの検索結果を親レコードとともに表示する前に、タスク [task] テーブルのインデックスを手動で再作成する必要があります。テーブルのインデックスの再作成の詳細については、「単一のインデックス付きソースに対して完全なテーブルインデックス作成またはインデックス再作成を実行する」を参照してください。
注:
タスクテーブルのインデックスの再作成には時間がかかる場合があります。
以前のリリースから Vancouver にアップグレードした後、必要に応じて、ブロックおよび昇格アクションを含む結果改善ルールを含む検索プロファイルを再公開できます。これらの検索プロファイルを再公開すると、結果改善ルールが翻訳された検索結果を正しくブロックまたは昇格できない可能性がある問題が解決されます。検索プロファイルを再公開する手順については、「Publish a search profile (検索プロファイルを公開する)」を参照してください。AI 検索で翻訳されたコンテンツを処理する方法の詳細については、「Internationalization support for AI Search (AI 検索のインターナショナリゼーションサポート)」を参照してください。

Vancouver

アセスメントとサーベイ

Utah より前のバージョンから Vancouver にアップグレードする場合は、自動テストフレームワーク (ATF) テストを更新します。Utah リリースでは、アセスメントカードとサーベイカードのボタンをすべて削除しました。ATF テストを正常に実行するには、このステップを含むすべてのテストについて、「サーベイの実施ボタンをクリックする」ステップを「サーベイカードをクリックする」のステップに置き換える必要があります。

Vancouver

自動テストフレームワーク (ATF)

Vancouver

クラウドコスト管理

クラウドコスト管理を Vancouver にアップグレードする手順については、「クラウドインサイトのアップグレード」を参照してください。

Vancouver

構成管理データベース (CMDB)

アップグレード中に、調整定義マッピング [cmdb_reconciliation_definition_mapping] テーブルを再ペアレンティングする修正スクリプトが実行されます。この修正スクリプトが完了するまでの時間は、アップグレードされたインスタンスの調整ルールの数によって異なり、通常はアップグレードに数分かかります。

調整定義マッピング [cmdb_reconciliation_definition_mapping] テーブルを再ペアレンティングすることは、インスタンス間で調整ルールをエクスポートするときにそのテーブルのデータが更新セットによってキャプチャされるようにするために必要です。アップグレード後、調整ルールへの変更は更新セットによって完全にキャプチャされ、宛先インスタンスに適切に移植されます。

Vancouver

カスタマーサービス管理 (CSM)

Vancouver リリースへのアップグレード後に、カスタマーサービスのタスクインテリジェンスのカテゴリ化および感情モデルの再トレーニングと再展開が必要になる場合があります。詳細については、カスタマーサービスのタスクインテリジェンスのドキュメントの「Steps to complete after upgrading to Vancouver (Vancouver にアップグレードした後に完了するステップ)」を参照してください。

Vancouver

ドキュメントインテリジェンス (DocIntel)

ドキュメントインテリジェンス (DocIntel) 3.0 以降には、スコープ対象のアプリケーションから Now Platform プラグインへの移行をサポートする更新されたスキーマが含まれています。アップグレードの詳細については、「バージョン 2.4 以前からドキュメントインテリジェンス (DocIntel) 3.0 へのアップグレード」を参照してください。

Vancouver

ゴールフレームワーク

v4.2.0 以降、[タイプ] フィールドが [マイルストーン] に設定されている既存のターゲットは、定性的ターゲットと見なされます。ゴールフレームワークをアップグレードすると、このような既存のターゲットの場合、測定単位は [はい]/[いいえ] に設定され、[基準] の値は [いいえ] に設定され、[ターゲット] の値は自動的に [はい] に設定されます。また、進捗値が 100 の場合、[実績] の値は [はい] に設定され、それ以外の場合は [いいえ] に設定されます。

Vancouver

ITOM ヴィジビリティ

Microsoft Azure アラート構成: アップグレード後、Microsoft Azure アラートサービスを構成して、アラート通知を安全な方法で Now Platform に転送します。詳細については、「セキュアな Webhook を使用して Microsoft Azure アラートを Now Platform に転送する」を参照してください。

Vancouver

ID と認証

認証 report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、Vancouver リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。

Vancouver

産業用プロセスマネージャー

Vancouver

インスタンスデータレプリケーション (IDR)

レプリケーションセットを V2 にアップグレードして Hermes Messaging Service を使用すると、インスタンスデータレプリケーション (HLA) のパフォーマンスと処理効率が向上します。詳細については、「Upgrading legacy replication set to V2 in インスタンスデータレプリケーション (IDR) (インスタンスデータレプリケーション (IDR) の V2 への従来のレプリケーションセットのアップグレード)」を参照してください。

インスタンスのレプリケーションペイロードエラー [idr_replication_payload_error] テーブルに 1,000 万件を超えるレコードがある場合は、KB1364728 に従ってテーブルローテーションを設定します。テーブルローテーションを使用してレプリケーションペイロードエラー [idr_replication_payload_error] テーブルからレコードを削除すると、このテーブルには HLA によってログに記録されたレプリケーションエラーのみが含まれ、レプリケートされたデータは含まれないため、安全です。

Vancouver

MID サーバー

最新の MID サーバーシステム要件については、「MID Server system requirements (MID サーバーシステム要件)」を参照してください。サポートされている JRE の最小バージョンは 11.0.9 で、推奨バージョンは 11.0.16.1 です。

アップグレードの際に MID サーバーがサポートされていないバージョンの JRE を使用している場合、アップグレードプロセスで JRE の最低バージョンと推奨バージョンを示す警告メッセージが表示されます。
サポートされている JRE が MID サーバーホストで実行されている場合、アップグレードされた MID サーバーはそのバージョンを使用します。

MID サーバーのアップグレードについて詳しくは次のトピックを参照してください。

MID サーバーのアップグレード前のチェック：実際にアップグレードを行なう前に、システムでの MID サーバーのアップグレード機能を AutoUpgrade モニターでテストする方法を説明しています。
手動での MID サーバーのアップグレード：MID サーバーを手動でアップグレードする方法について説明しています。

Vancouver

Now Assist

Now Assist アプリケーションとプラグインのアップグレードのトラブルシューティングの詳細については、Now Assist アップグレードの問題と軽減に関する KB 記事を参照してください。

Vancouver

注文管理

2023 年 11 月のリリース以降、注文管理アプリケーションは、電気通信、メディア、テクノロジー向け注文管理アプリケーションで提供される注文履行機能を含む、製品およびサービスの注文の完全なライフサイクルをサポートします。通信事業サービス管理サブスクリプションをお持ちの場合は、ServiceNow Store から電気通信、メディア、テクノロジー向け注文管理アプリケーションをインストールします。このアプリケーションは、注文管理アプリケーション、通信デモデータ、および TM Forum API REST 仕様の次の ServiceNow オープン API 実装をインストールします。

製品カタログオープン API
サービスカタログオープン API
製品注文オープン API
サービス注文オープン API
製品インベントリオープン API
テクニカルサービス認定オープン API

カスタマーサービス管理 (CSM) の注文管理アプリケーションに精通している場合は、注文管理アプリケーションをインストールした後、オプションでそのインターフェイスを使用できます。詳細については、「Enable the user interface for Order Management for Customer Service Management (カスタマーサービス管理 (CSM) の注文管理のユーザーインターフェイスを有効にする) KB1554296」を参照してください。インターフェイスの変更については、「カスタマーサービス管理 (CSM) の注文管理アプリケーションの変更 (Changes to the Order Management for Customer Service Management application) KB1560237」を参照してください。

アップグレード中、注文タスク [sn_ind_tmt_orm_order_task] テーブルは、カスタマーサービス管理 (CSM) アプリケーションで使用される予定タスク [planned_tasks] テーブルから拡張されます。注文タスクテーブルも変更されました。注文タスクテーブルの変更に関する詳細については、「OMT Reparenting data model changes (OMT 再親化データモデルの変更) KB1496935」を参照してください。

Vancouver リリースにアップグレードしたが、電気通信、メディア、テクノロジー向け注文管理アプリケーションのバージョン 5.2.0 を使用していない場合、製品インベントリおよび製品モデル特性を設定するための修正は利用できません。これらの変更を取得するには、現在の Vancouver パッチにアップグレードします。

Vancouver

プラットフォームアナリティクスワークスペース

プラットフォームアナリティクスワークスペース (3.0) の Vancouver バージョンには、以前は ServiceNow® Store でのみ利用可能だったバージョン 2.1.x の更新が含まれています。

Vancouver

ポートフォリオ計画

古いバージョンからポートフォリオ計画 v6.1.1 以降にアップグレードする場合は、roadmap_editor ロールが使用されなくなるため、roadmap_editor ロールから milestone_editor ロールを削除する修正スクリプトが実行されます。この場合、ServiceNow インスタンスに roadmap_editor ロールを持つ多数のユーザーがいると、アップグレードが完了するまでに時間がかかることがあります。詳細については、KB1443618 を参照してください。
古いバージョンからポートフォリオ計画 7.0.0 または 7.1.0 にアップグレードする場合、ポートフォリオ計画の作成または編集中にエンティティの選択ステップでエンティティリストがロードされないことがあります。この場合、[エンティティを選択] ページのリストコンポーネントにスクリプトを追加する必要があります。詳細については、KB1566418 を参照してください。

Vancouver

プロセスオートメーションデザイナー

Vancouver にアップグレードした後、ServiceNow Store でアプリケーションを更新します。

Vancouver

公共機関デジタルサービス

公共機関デジタルサービス v8.0 にアップグレードする前に、[提供されるサービス] テーブルのデータ、[受けたサービス] テーブルのデータ、および [提供されるサービス] テーブルから [サービス定義] テーブルへの変換によって影響を受けるその他すべてのデータ (パフォーマンスアナリティクスダッシュボードデータ、構成員またはビジネスレポートデータなど) のカスタムサービス定義を作成する必要があります。以前のリリースで作成されたカスタムサービス提供データと受けたサービスデータは、新しいリリースに自動的に移行されず、アップグレード後は、データが従来のエンティティからサービス定義テーブルに移行されるまで、アプリケーション内でアクセスできなくなります。詳細については、「提供されるサービスと受けたサービスの移行ガイダンス (Services Offered and Services Received Migration Guidance)」および「公共機関デジタルサービスでのプレイブックのサービス定義の構成 (Configure a service definition for Playbooks in Public Sector Digital Services)」を参照してください。

Vancouver

ロボティックプロセスオートメーション (RPA) ハブ

現在インストール済みの Microsoft Software Installers (MSI) (RPA デスクトップデザインスタジオ、アテンド型ロボット、無人ロボット、および無人ロボット Login Agent) は、RPA アプリケーションをダウンロードして必ずアップグレードしてください。詳細については、「Download the RPA applications from RPA Hub (RPA ハブからの RPA アプリケーションのダウンロード)」を参照してください。

次のアップグレード手順は、San Diego または Tokyo から Vancouver にアップグレードする場合にのみ適用されます。

アプリケーションファイルテーブル内のレコード数に応じて、RPA Hub アプリケーションについて、Tokyo からのアップグレード中、または Vancouver へのアップグレードの前に、遅延が生じる可能性があります。

RPA Hub を Vancouver にアップグレードする前に、glide.rollback.blacklist.TableParentChange.change システムプロパティの値を false に設定する必要があります。このプロパティがシステムプロパティ [sys_properties] テーブルに存在しない場合は、プロパティを追加し、その値を false に設定します。

Vancouver にアップグレードすると、ボットプロセス定義は新しい構造、つまりボットプロセス構成に変更されます。ただし、ボットプロセス構成がボットプロセスを完全に置き換えるわけではありません。ほとんどのフィールドがボットプロセスからボットプロセス構成に移動されます。

Vancouver

セキュリティインシデントレスポンス

Vancouver

サービスブリッジ

新しいサービスブリッジアプリケーションのアップグレードと使用の詳細については、「サービスブリッジからの移行 (レガシー)」を参照してください。

Vancouver

Service Operations Workspace for ITSM

次のアプリケーションに互換性のあるアップグレードバージョンが存在することを確認します。

サービスオペレーションワークスペース ITSM Applications アプリケーション (sn_sow_itsm_cont)
サービスオペレーションワークスペース ITOM アプリケーション (sn_sow_itom_cont)

表 : 6. 互換性のある SOW バージョン
SOW-ITSM (sn_sow_itsm_cont)	SOW-ITOM (sn_sow_itom_cont)
1.1.x	21.0.y
1.2.x	21.1.y
1.3.x	21.2.y、21.5.y、および 21.6.y
2.0.x	22.0.y
2.1.x	22.1.y および 22.y.y
4.0.x	24.y.y

アップグレードされたインスタンスに次のいずれかのカスタマイズが含まれている場合は、標準レコードページの変更を移行する必要があります。詳細については、「サービスオペレーションワークスペースの標準レコードページの構成」を参照してください。

クライアントタイプの任意のカスタム宣言アクション
任意のカスタムモーダル
カスタム水平タブまたはコンテキストサイドパネルタブの画面または画面条件

3.0 のアップグレード後は、推奨フレームワーク機能は使用できなくなり、代わりに Recommended Actions for ITSM 機能の標準バージョンのみが使用できます。

Vancouver

サービスポータル

アップグレード後に、テーブル入力パラメーターを受け入れる公開ウィジェットのデータにゲストユーザーがアクセスできるテーブルを指定する必要があります。デフォルトでは、Vancouver パッチ 7 リリース以降では、テーブル入力パラメーターを受け入れる公開ウィジェットは、ゲストユーザーのどのテーブルからもデータにアクセスして返すことができません。アップグレード前に glide.service_portal.widget.table_allow_list または glide.service_portal.widget.allow_list システムプロパティを追加した場合、これらのプロパティの値は、Vancouver パッチ 7 リリース以降にアップグレードした後にウィジェットの公開テーブル許可リストに移行されます。詳細については、「ウィジェットセキュリティの構成」を参照してください。

Vancouver

サービスポートフォリオ管理

可用性の結果の表示は Tokyo リリースで導入されましたが後続のリリースにも適用されます。アップグレードすると、データ負荷が高いと判断されたお客様の場合、システムが長時間実行型のバックグラウンドジョブを開始し、長い時間継続する場合があります。詳細については、「KB1123644」を参照してください。

Vancouver

スキル管理

[スキルを管理] ページの URL をカスタマイズした場合は、新しいページを指すように URL を手動で更新する必要があります。新しい [スキルの管理] ページへの相対パスは次のとおりです：https://<instance name>.service-now.com/now/nav/ui/manage-skills/params/parent-skill/2eb1c2029f100200a3bc1471367fcfe4/parent-department/221f79b7c6112284005d646b76ab978c/recursive-departments/true/recursive-skills/true/group-by/department。既存のパスをこのパスに置き換えることができます。

注:

parent-skill と parent-department の sys_id が、既存の URL にあるものと同じ ID であることを確認してください。

Vancouver

ソフトウェア資産管理

Vancouver にアップグレードすると、ディスカバリーマップ (DMAP) 定義の [バージョン] フィールドと [エディション] フィールドで新しい is_empty 値がサポートされます。既存の Microsoft SQL Server コンポーネント DMAP 定義の [エディション] フィールドが以前に is_anything に設定されていた場合、コンテンツの更新後に新しい is_empty 値で自動的に更新されます。

Vancouver

戦略的計画

v2.1.0 以降、Strategic Planning の目標モジュールにアクセスするには、読み取りアクセスと編集アクセスにそれぞれ sn_apw_advanced.spw_goal_user_read ロールと sn_apw_advanced.spw_goal_user ロールが必要です。Strategic Planning をアップグレードした後、これらのロールを既存の目標ユーザーにアサインして、Strategic Planning で目標を管理します。
v2.1.0 以降、[タイプ] フィールドが [マイルストーン] に設定されている既存のターゲットは、定性的ターゲットと見なされます。Strategic Planning をアップグレードすると、このような既存のターゲットの場合、自動的に測定単位は [はい]/[いいえ] に設定され、基準値は [いいえ] に設定され、ターゲット値は [はい] に設定されます。また、進捗値が 100 の場合、[実績] の値は [はい] に設定され、それ以外の場合は [いいえ] に設定されます。
古いバージョンからポートフォリオ計画立案 v2.1.0 以降にアップグレードする場合は、roadmap_editor ロールが使用されなくなるため、roadmap_editor ロールから milestone_editor ロールを削除する修正スクリプトが実行されます。この場合、ServiceNow インスタンスに roadmap_editor ロールを持つ多数のユーザーがいると、アップグレードが完了するまでに時間がかかることがあります。詳細については、KB1443618 を参照してください。
古いバージョンから Strategic Planning v3.0.0 または v3.4.0 にアップグレードする場合、ポートフォリオ計画の作成または編集中にエンティティの選択手順でエンティティリストがロードされないことがあります。この場合、[エンティティを選択] ページのリストコンポーネントにスクリプトを追加する必要があります。詳細については、KB1566418 を参照してください。

Vancouver

通信事業サービスオペレーション管理

統合ハブスターターパッケージは、外部トリガーとともに、Vancouver パッチ 1 のスターターパッケージのコンポーネントとして含まれています。顧客は、電気通信 API 通知機能を取得するには、ファミリーリリースの Vancouver パッチ 1 を使用する必要があります。

Vancouver

サードパーティリスク管理

Vancouver

仮想エージェント

Vancouver パッチ 7 で提供されるいくつかの機能は、最初の Washington DC 早期アクセスリリースでは使用できません。これらの機能は、Washington DC の将来のパッチリリースで利用可能になります。

入力コレクターのコントロールの変更

ドラッグアンドドロップしてノード内の入力を並べ替えます。
ノードが受け入れる入力のタイプ (テキスト、メール、IP アドレス、電話番号、URL、またはカスタム) を指定します。
ノードあたりの入力の最大数は 5 です。

テキストユーザー入力コントロールで強制されるユーザープロンプトオプション

[詳細プロパティ] 領域の切り替えスイッチを使用すると、トピック作成者が、LLM によって生成される応答の代わりにユーザーに表示されるメッセージを指定できます。

Vancouver

脆弱性対応統合

脆弱性対応アプリケーションのリリース済みバージョンと、Vancouver と互換性のあるサードパーティアプリケーションや ServiceNow アプリケーションについて、詳しくは、ナレッジベース記事「Vulnerability Response Compatibility Matrix and Release Schema Changes (脆弱性対応互換性マトリクスおよびリリーススキーマの変更点) [KB0856498]」を参照してください。
脆弱性対応の新機能の詳細については、「脆弱性対応リリースノート」を参照してください。

Vancouver

脆弱性対応

脆弱性対応アプリケーションのバージョン 20.0 および脆弱性緊急対応アプリケーションのバージョン 2.03 以降、「脆弱性アナリストワークスペース」は「脆弱性アセスメントワークスペース」という名前に変更されています。「脆弱性アナリストワークスペース」への参照はすべて「脆弱性アセスメントワークスペース」になりました。

Vancouver

AI 検索

Washington DC にアップグレードすると、AI 検索で既存の Genius 結果構成が自動的に更新され、新しい AI 検索 Genius 結果構成フォームのフィールドを使用するようなります。この更新手順では、以下のような変更が行われます。

[Genius 結果の回答タイプ] フィールドの既存の値を削除します。
必要に応じて、[Genius 結果のロジック] フィールドの値を、新しい AI 検索要求プロセッサーのフィールドと AI 検索応答プロセッサーのフィールドに移行します。

インスタンスを Washington DC にアップグレードした後も、AI 検索は、以前に [検索クエリに複数の用語が含まれている場合に使用するブーリアン検索演算子] ( glide.ais.query.search_operator ) システムプロパティに設定した値を保持します。マルチターム検索に対して新たに拡張されたクエリモードを活用するには、このシステムプロパティの値を AND then OR 2+ key terms に設定します。AI 検索システムプロパティの詳細については、「AI 検索システムプロパティ」を参照してください。

Washington DC 以降、ユーザー [sys_user] テーブルではデフォルトで、インデックス付きレコードは sys_updated_on の日付でソートされず、sys_created_on の日付でソートされます。この変更では、AI 検索のユーザーテーブルのインデックス付きソースのインデックスを再作成する必要があるため、時間がかかる可能性があります。以前のファミリーリリースから Washington DC にアップグレードすると、AI 検索ではユーザーテーブルのインデックス付きソースのインデックスが自動的に再作成されません。ユーザーレコードの最新の構成を検索可能にする必要がある場合、ユーザーテーブルのインデックス付きソースのインデックスを手動で再作成することはできますが、時間がかかる可能性があります。そうでない場合は、すべてのレコードのインデックスが再作成されるまで、更新時に個々のユーザーテーブルレコードのインデックスが AI 検索によって再作成されます。

Washington

自動テストフレームワーク (ATF)

Washington

事業継続性管理

Washington DC リリースにアップグレードした後には、既存のビジネスインパクトアナリシス、事業継続性計画、およびイベントについて、次の重要な情報に注意する必要があります。

ビジネスインパクトアナリシスの場合、アップグレード後に手動で追加された依存関係について、依存関係アセスメントの [ソース] 列の名前が [プライマリソース] に変更され、BCM ソースの名前が [手動] に変更されます。[依存関係を更新 (Update dependencies)] ボタンを選択すると、CMDB 依存関係が追加されます。
事業継続性計画については、アップグレード後に [ソース] 列の名前が [プライマリソース] に変更されます。[依存関係を更新 (Update dependencies)] ボタンを選択すると、CMDB および BIA 依存関係が追加されます。以前のリリースとの互換性を維持するために、BCM アドミニストレーターはソースを構成し、BIA アップストリーム依存関係と BIA ダウンストリーム依存関係のみをソースとして更新された構成に保持できます。
イベントと演習で、[依存関係を更新 (Update dependencies)] ボタンを選択すると、アップグレード後に CMDB、BIA、および事業継続性計画 (BCP) の依存関係が追加されます。以前のリリースとの互換性を維持するために、BCM アドミニストレーターはソースを構成し、BIA アップストリーム依存関係と BIA ダウンストリーム依存関係のみをソースとして更新された構成に保持できます。

Washington DC

構成管理データベース (CMDB)

この列 product_instance_id は、新しい製品インスタンス識別子 (PID) をサポートすることを目的としてベース構成アイテム [cmdb_ci] テーブルに追加されました。これにより、既存の関連資産、CI、およびインストールベースアイテム (IBI) のルックアップとリンクが可能になります。アップグレード中の変更の影響とその影響を最小限に抑える方法の詳細については、ナレッジベースの記事「Washington リリースに対する CMDB_CI スキーマの変更のアップグレード時の影響 (Upgrade impact of CMDB_CI schema changes for Washington release) [KB1534035]」を参照してください。
Washington DC リリースへのアップグレード後に初めて CMDB 360 を有効にする場合、非 CMDB クラス (構成アイテム [cmdb_ci] クラスから派生していないクラス) からの CI に対する CMDB 360 データのキャプチャを有効にするには、glide.identification_engine.multisource_non_cmdb_ci_enabled システムプロパティを true に設定する必要があります。
コア UI で従来のデータ認定アプリケーションを使用していた場合、CMDB ワークスペースでのデータ認定の新しい実装では、関連する定義を使用できません。Washington DC リリースおよび CMDB ワークスペースのバージョン 6.0 にアップグレードした後、従来のデータ認定アプリケーションで作成された定義は、CMDB ワークスペースでドラフトのデータマネージャー認定ポリシーに変換できます。詳細については、「」を参照してください。

Washington DC

Core Now Platform

以前は、トランザクションがキャンセルされた場合に、特定の監査可能な操作が記録されませんでした。監査レコードがなくなるこの動作が発生するのは、レコードの変更中にプラットフォームがなんらかの操作を実行し、監査の作成前にその操作がキャンセルされるためです。しかし現在では、レコードが変更された直後に監査が作成されるため、キャンセルされたトランザクションによって、監査が記録される前に操作が中止される可能性が低くなります。この更新を容易にするために、トランザクションと同じスレッドに監査が記録されるようになりました。以前の監査はバックグラウンドスレッドで作成されていました。

この変更により、 glide.db.audit.lazy プロパティのデフォルト値が true から false に再定義されます。理想的には、このプロパティはプロパティテーブルで定義されていません。つまり、大半のインスタンスで Washington DC リリースで新しいデフォルト値と動作の使用が開始されるということです。インスタンスによっては、このプロパティが値を true に設定した状態で挿入されている可能性があります。これは、これらのインスタンスがこの変更を使用して動作を監査できないことを意味します。この更新を利用するには、このプロパティを削除してください。

Washington DC

暗号化キー管理

インスタンスを Washington DC にアップグレードしても、MID サーバーをアップグレードしない場合、シークレット管理認証は失敗します。MID サーバーを Washington DC にアップグレードすることで、認証エラーを回避します。アップグレードできない場合は、認証の失敗を避けるために、MID サーバーが Washington DC にアップグレードされるまでは認証をオフにする必要があります。

MID サーバーのアップグレード詳細については、「MID サーバーのアップグレード」を参照してください。

Washington DC

エンタープライズ資産管理

Washington DC にアップグレードすると、エンタープライズ資産 [sn_ent_asset] テーブルで [model_component] フィールドを使用できなくなります。代わりに、資産 [alm_asset] テーブルで新しい model_component_id フィールドが使用可能になります。[ENT - Migrate to new model] コンポーネントスクリプトによって、既存の model_component フィールドデータが model_component_id フィールドに移動します。

資産の総所有コスト (TCO) については、次のアップグレードシナリオに注意してください。

アップグレードは、すべてのエンタープライズ資産管理フロータスクに対して機能します。
ワークフロータスクごとにタスクのレートカードが必要です。
TCO のアップグレードにより、各タスクに対応する経費ラインの [資産] および [経費カテゴリ] フィールドにデータが入力されます。
経費カテゴリは、経費ラインと経費ラインのソースに基づいて入力されます。
既存のすべてのモデルの [TCO ベンチマークコスト] と [TCO ベンチマークしきい値] フィールドに手動で入力するか、一括インポート機能を使用して入力する必要があります。
TCO をアップグレードすると、資産フォームの次のフィールドが入力されます。
- 資産の残存有効年限の終了：作成日に残存有効年限を月単位で加算したもの。
- 資産の最初の使用日：作成日。
- 資産 TCO：資産に関連するすべての経費ラインの合計。単純な資産の場合、資産 TCO はその下の経費ラインの合計です。複合資産の場合、資産 TCO は、親資産とその子資産の経費ラインの合計です。

Washington DC

ファイナンシャルサービスオペレーションコア

Washington DC へのアップグレード中に、ファイナンシャルサービスオペレーションコアプラグインは次のテーブルを再ペアレンティングします。

注:

アップグレードされたインスタンス内のレコードの数が多い場合、アップグレードの完了までに長時間かかることがあります。

サービス定義 [sn_bom_service_definition] テーブルは、要求定義 [sn_ind_request_definition] ではなくサービス定義 [sn_case_type_selection] テーブルから拡張されます。
財務タスク [sn_bom_task] テーブルは、グローバルタスク [task] テーブルの代わりにカスタマーサービスタスク [sn_customerservice_task] テーブルから拡張されます。
ポリシー参加者 [sn_bom_policy_participant] テーブルは、販売済み製品の関連当事者 [sn_install_base_sold_product_related_party] テーブルから拡張されます。

再ペアレンティングにより、既存のアプリケーションの機能を維持したまま、ServiceNow® カスタマーサービス管理 (CSM) のメリットと高機能を活用できます。

Washington DC

ハードウェア資産管理 10.0.0

Washington DC にアップグレードした後は、資産の総所有コスト (TCO) について、次のアップグレードシナリオに留意してください。

アップグレードは、すべてのハードウェア資産管理フロータスクに対して機能します。
ワークフロータスクごとにタスクのレートカードが必要です。
TCO のアップグレードにより、各タスクに対応する経費ラインの資産および経費カテゴリフィールドにデータが入力されます。
経費カテゴリは、経費ラインと経費ラインのソースに基づいて入力されます。
既存のすべてのモデルの [TCO ベンチマークコスト] と [TCO ベンチマークしきい値] フィールドに手動で入力するか、一括インポート機能を使用して入力する必要があります。
TCO をアップグレードすると、資産に関する次のフィールドが入力されます。
- 資産の残存有効年限の終了：作成日と月単位の残存有効年限。
- 資産の最初の使用日：作成日と同じ。
- 資産 TCO：資産に関連するすべての経費ラインの合計。単純な資産の場合、資産 TCO はその下の経費ラインの合計です。複合資産の場合、資産 TCO は、親資産とその子資産の経費ラインの合計です。

Washington DC

ヘルスケアとライフサイエンスサービス管理 Core

Washington DC へのアップグレード中に、ヘルスケア販売済み製品 [sn_hcls_sold_product] 親テーブルが、次のテーブルのインストールベースアイテム [sn_install_base_item] に変更されます。

メンバープラン [sn_hcls_member_plan]
薬剤 [sn_hcls_medium]
予防接種 [sn_hcls_immunization]
登録済みプログラム [sn_hcls_enrolled_program]
登録済みプログラムサービス [sn_hcls_enrolled_program]

また、次のテーブルは親テーブルが削除されてスタンドアロンテーブルになっています。

医療機関 [sn_hcls_organization]
医療機関の所在地 [sn_hcls_location]
施術者所在地 [sn_hcls_practitioner_facility]

このように親を指定し直すことで、顧客がより広範なユースケースに組織テーブルと場所テーブルを使用できるようになります。

既存のデータは、既存の機能が影響を受けないよう、次の方法で移行されます。

sn_hcls_immunization の場所フィールドの参照が cmn_location を使用するように更新されました。
すべてのデータが、ヘルスケア販売済み製品テーブルからインストールベースアイテムテーブルに移動されます。
影響を受けるインストールベースアイテムの行は、ヘルスケア販売済み製品の source_task の値に基づいて入力されます。
sn_hcls_enrolled_program と sn_hcls_enrolled_program_service のステータスが hcls_state からコピーされます。
すべてのデータは、医療機関、医療機関の場所、および施術者所在地のスタンドアロンテーブルに移動します。
1. このスクリプトにより、[医療機関] テーブルにある既存のレコードの [事業所] テーブルにレコードが作成され、1 対 1 の参照が形成されます。
2. サービス組織を参照するレコードは、適切な事業所への参照によって更新されます。
3. 施術者所在地にレコードを持つ施術者には、適切な事業所を含めて [サービス組織メンバー] テーブルにレコードが作成されます。
4. 医療機関の所在地のデータを含むレコードには、その医療機関の所在地の親サービス組織が含まれます。

注:

アップグレードされたインスタンス内のレコードの数が多い場合、アップグレードの完了までに長時間かかることがあります。

Washington DC

産業用プロセスマネージャー

産業用プロセスマネージャーアプリケーションは、オペレーショナルテクノロジーインシデント管理およびオペレーショナルテクノロジー変更管理を含む Operational Technology Service Management アプリケーションと依存関係を持つようになりました。産業用プロセスマネージャーをインスタンスにインストールするには、次のいずれかの SKU が必要です。

オペレーショナルテクノロジーヴィジビリティ SKU
Operational Technology Service Management SKU
産業用プロセスマネージャーの資格を付与するカスタム SKU

Washington DC

インスタンスデータレプリケーション (IDR)

アップグレード後に、レプリケーションペイロードエラー [idr_replication_payload_error] テーブルのログローテーションが自動的に有効になります。デフォルトでは、ログローテーションスケジュールは 7 つのシャードで構成され、シャードごとに 5 日間です。アップグレード前に作成された当該テーブルのログエントリはすべて自動的に切り捨てられます。

Washington DC

MID サーバー

アップグレードの際に MID サーバーがサポートされていないバージョンの JRE を使用している場合、アップグレードプロセスで JRE の最低バージョンと推奨バージョンを示す警告メッセージが表示されます。
サポートされている JRE が MID サーバーホストで実行されている場合、アップグレードされた MID サーバーはそのバージョンを使用します。

1 つの実行可能ファイルパスにつき、 Windows MID サーバーサービスは 1 つのみ許可されます。アップグレードした Windows MID サーバーに同じインストールフォルダーを指しているサービスが複数ある場合は起動できません。詳しくは「MID Server fails to start (MID サーバーが起動しない)」を参照してください。

MID サーバーのアップグレードについて詳しくは次のトピックを参照してください。

MID サーバーのアップグレード前のチェック：実際にアップグレードを行なう前に、システムでの MID サーバーのアップグレード機能を AutoUpgrade モニターでテストする方法を説明しています。
手動での MID サーバーのアップグレード：MID サーバーを手動でアップグレードする方法について説明しています。

Washington DC

クリエーターの Now Assist

ワークフロースタジオのパフォーマンスを改善するには、ServiceNow Store からこれらのバージョンのワークフロースタジオアプリケーションのいずれかをインストールします。ワークフロースタジオのアップグレードの詳細については、「ワークフロースタジオの最新バージョンへの更新」を参照してください。

表 : 7. フロー生成スキルのアップグレードパス
クリエーターの Now Assist は既にインストールされていますか？	アップグレードに使用するワークフロースタジオのバージョン
いいえ	ワークフロースタジオをバージョン 25.1.3 にアップグレード
はい	ワークフロースタジオをバージョン 25.0.0 にアップグレード

Washington DC

Now Assist

Washington DC

注文管理

この Washington DC リリースで導入された機能は、注文管理の以前のリリースではサポートされていません。

通信事業とメディア向け注文管理バージョン 6.0 以前からアップグレードする場合：

Washington DC リリース以降では、製品オファリングと製品属性の特性に設定された毎月の定期料金 (MRC) と非定期料金 (NRC) は、製品オファリングデータモデルではなく、価格リストと価格明細の価格設定データモデルに保存されますWashington DC にアップグレードした後に価格リストを使用するように価格情報をアップグレードする場合は、Now Support ナレッジベースの記事「Washington にアップグレードする電気通信、メディア、およびテクノロジーの顧客向けの Price Management プラグイン (com.sn_csm_pricing) の取り込み (Price Management Plugin (com.sn_csm_pricing) uptake for Telecommunications, Media, and Technology customers upgrading to Washington) [KB1585863]」を参照してください。
リリースにアップグレードすると、修正スクリプトが自動的に実行され、未完了の注文のキャプチャを再開するために不要になった特定の電気通信リストレコードが非アクティブになります。これらのレコードの詳細と以前の注文キャプチャプロセス (必要な場合) の使用については、Now Support ナレッジベースの記事「Deprecating List for Order Capture [KB1586538] (注文キャプチャのリストの廃止)」を参照してください。

Washington DC リリースにアップグレードした後、製品コンフィギュレーターの使用中に、新しい変更指示や、切断、一時停止、または再開アクションを含む注文を処理するための再構成ワークアラウンドを確認します。詳細については、Now Support ナレッジベースの記事「Order line reconfiguration issues in Washington when using Order Capture UI [KB1585976] (Washington で注文キャプチャ UI を使用する際の注文ライン再構成の問題)」を参照してください。

Washington DC

注文管理

この Washington DC リリースで導入された新機能は、Order Management for Telecommunications, Media, and Technology の以前のリリースではサポートされていません。

Washington DC リリース以降では、製品オファリングと製品属性の特性に設定された毎月の定期料金 (MRC) と非定期料金 (NRC) は、製品オファリングデータモデルではなく、価格リストと価格明細の価格設定データモデルに保存されます。Washington DC にアップグレードした後に価格リストを使用するように価格情報をアップグレードする場合は、Now Support ナレッジベースの記事「Washington にアップグレードする電気通信、メディア、およびテクノロジーの顧客向けの Price Management プラグイン (com.sn_csm_pricing) の取り込み (Price Management Plugin (com.sn_csm_pricing) uptake for Telecommunications, Media, and Technology customers upgrading to Washington) [KB1585863]」を参照してください。

Washington DC リリースにアップグレードすると、修正スクリプトが自動的に実行され、未完了の注文のキャプチャを再開するために不要になった特定の電気通信リストレコードが非アクティブになります。これらのレコードの詳細と以前の注文キャプチャプロセス (必要な場合) の使用については、Now Support ナレッジベースの記事「注文キャプチャの電話会社リストの廃止 (Deprecating Telco List for Order Capture) [KB1586538]」を参照してください。

Washington DC にアップグレードした後、製品コンフィギュレーターの使用中に、新しい変更指示や、切断、一時停止、または再開アクションを含む注文を処理するための再構成ワークアラウンドを確認します。詳細については、Now Support ナレッジベースの記事「Washington で注文キャプチャ UI を使用する際の注文ライン再構成の問題 (Order line reconfiguration issues in Washington when using Order Capture UI) [KB1585976]」を参照してください。

Washington DC

パフォーマンスアナリティクス

従来の PA スコア [pa_scores] テーブルは廃止されます。PA スコアテーブルにキャプチャされたインジケータースコアがまだ存在する場合、スコアの数が 4,300 万未満であれば、そのスコアはアップグレード時に pa_scores_l1 テーブルと pa_scores_l2 テーブルに自動的に移行されます。アップグレードに追加される予想時間は約 2 時間です。詳細については、KB1294371 または「パフォーマンスアナリティクススコアの移行」を参照してください。

Washington DC

プラットフォームアナリティクスエクスペリエンス

プラットフォームアナリティクスエクスペリエンス機能は、以前はプラットフォームアナリティクスワークスペースにありました。この機能は Core Now Platform の一部となり、ネクストエクスペリエンス統一ナビゲーションからアクセスできるようになりました。コア UI で作成されたダッシュボード、レポート、およびパフォーマンスアナリティクスウィジェットをこの機能に移行できます。

Washington DC

ワークフロースタジオのプレイブック

Washington DC にアップグレードした後、ServiceNow Store のプレイブックおよびワークフロースタジオアプリケーションを更新します。

Washington DC

ポートフォリオ計画

v8.0.0 以降、戦略的ポートフォリオ管理 (SPM) Pro ライセンス機能には、戦略的計画ワークスペースでのみアクセスできます。ポートフォリオ計画ワークスペースを使用して、SPM Pro ライセンスの機能 (目標、製品フィードバック、ハイブリッドポートフォリオ計画など) にアクセスしている場合、そのような機能にアクセスするには Strategic Planning をインストールする必要があります。戦略的計画ワークスペースでのみアクセスできる機能の詳細については、「ポートフォリオ計画と Strategic Planning の比較」を参照してください。

Washington DC

予測インテリジェンス

Washington DC にアップグレードすると、新しい回帰ソリューションを作成できなくなります。既存のソリューションがある場合、そのソリューションは引き続きサポートされ、トレーニングと変更はできますが、新しいソリューションを作成することはできません。

類似性ソリューションとクラスタリングソリューションへの変更は、Washington DC にあるすべてのインスタンスに適用されます。

Washington DC

Proactive Service Experience Workflows

トラブルチケット通知を受信したくない顧客は、インシデントテーブルとケーステーブルに関連するビジネスルールを無効にすることができます。トラブルチケット通知のビジネスルールを無効にする方法の詳細については、「トラブルチケット通知の非アクティブ化」を参照してください。

Washington DC

製品カタログ管理および Pricing Management

セールスと注文管理アプリケーションの初期リリースで標準価格調整マトリクスの属性特性を使用していて、セールスと注文管理アプリケーションの 2024 年 5 月リリースにアップグレードする場合は、自動生成されたコード値の形式を修正するスケジュール済みジョブを実行する必要があります。オンデマンドで特殊文字を含む特性レコードのコードフィールドを変更するスケジュール済みジョブを実行して、文字 (a ～ z、A ～ Z)、数字 (0 ～ 9)、アンダースコア (_)、またはドル記号 ($) 以外の文字をアンダースコア (_) に置き換えます。このジョブは、コード値を、アンダースコアで開始または終了しないように、数字で始まらないように、および連続するアンダースコアを含まないように修正します。

Washington DC

公共機関デジタルサービス

アップグレード後、CSM 構成可能ワークスペースの特定の公共部門メニューとメニューアイテムが元の CSM ラベル名に戻ります。公共部門用のこれらのアイテムに再レベル付けするには、顧客およびサービス組織の UX リストカテゴリを更新します。再ラベル付けの詳細については、[すべて] > [構成員サービス] > [管理] > [ガイド付きセットアップ]に移動し、[公共機関デジタルサービスの構成可能ワークスペース] > [ワークスペースのラベルを手動でカスタマイズ (Customize Workspace Labels Manually)]を選択してください。

Washington DC

ロボティックプロセスオートメーション (RPA) ハブ

RPA アプリケーションをダウンロードして、現在インストールされている次のいずれかの Microsoft ソフトウェアインストーラー (MSI) をアップグレードしてください。

RPA デスクトップデザインスタジオ
アテンド型ロボット
無人ロボット
無人ロボットログインエージェント

詳細については、「Download the RPA applications from RPA Hub (RPA ハブからの RPA アプリケーションのダウンロード)」を参照してください。

次のアップグレード手順は、San Diego または Tokyo から Washington DC にアップグレードする場合にのみ適用されます。

アプリケーションファイルテーブル内のレコード数に応じて、RPA Hub アプリケーションについて、Tokyo からのアップグレード中、または Washington DC へのアップグレードの前に、遅延が生じる可能性があります。

RPA Hub を Washington DC にアップグレードする前に、glide.rollback.blacklist.TableParentChange.change システムプロパティの値を false に設定する必要があります。このプロパティがシステムプロパティ [sys_properties] テーブルに存在しない場合は、プロパティを追加し、その値を false に設定します。プロパティの追加方法の詳細については、「システムプロパティを追加する」を参照してください。

Washington DC にアップグレードすると、ボットプロセス定義は新しい構造、つまりボットプロセス構成に変更されます。

ボットプロセス構成がボットプロセスを完全に置き換えるわけではありませんが、ほとんどのフィールドはボットプロセスからボットプロセス構成に移動されます。システムプロパティ値を更新せずに Utah バージョンにアップグレードすると、テーブルは [アプリケーションファイル] テーブルを拡張しません。テーブルの変更を手動で更新するには、Now Support ナレッジベースの記事「Restructuring RPA Hub tables to sys_metadata in Utah (Utah の sys_metadata への RPA Hub テーブルの再ビルド)」を参照してください。

Washington DC

セキュリティポスチャコントロール

セキュリティポスチャコントロールの実装に必要なアプリケーションの完全なリストについては、「セキュリティポスチャコントロールでサポートされるアプリケーションのインストール」を参照してください。

Washington DC

IT Service Management のサービスオペレーションワークスペース

次のアプリケーションに互換性のあるアップグレードバージョンが存在することを確認します。

サービスオペレーションワークスペース ITSM Applications アプリケーション (sn_sow_itsm_cont)
サービスオペレーションワークスペース ITOM アプリケーション (sn_sow_itom_cont)

表 : 8. 互換性のある SOW バージョン
SOW-ITSM (sn_sow_itsm_cont)	SOW-ITOM (sn_sow_itom_cont)
1.1.x	21.0.y
1.2.x	21.1.y
1.3.x	21.2.y、21.5.y、および 21.6.y
2.0.x	22.0.y
2.1.x	22.1.y および 22.y.y
3.1.x	23.y.y
4.x.x	24.y.y

テーブルでは、x はサービスオペレーションワークスペース ITSM アプリケーション (sn_sow_itsm_cont) のサブバージョンで、y はサービスオペレーションワークスペース ITOM アプリケーション (sn_sow_itom_cont) のサブバージョンです。

3.0 のアップグレード後、推奨フレームワーク機能は使用できなくなります。代わりに、Recommended Actions for ITSM 機能の標準バージョンのみを使用できます。

Washington DC

サービスポータル

アップグレード後に、テーブル入力パラメーターを受け入れる公開ウィジェットのデータにゲストユーザーがアクセスできるテーブルを指定する必要があります。Washington DC リリースのデフォルトでは、テーブル入力パラメーターを受け入れる公開ウィジェットは、ゲストユーザーのテーブルにアクセスしてデータを返すことはできません。アップグレード前に glide.service_portal.widget.table_allow_list または glide.service_portal.widget.allow_list システムプロパティを追加した場合、これらのプロパティの値は、アップグレード後にウィジェットの公開テーブル許可リストに移行されます。詳細については、「ウィジェットセキュリティの構成」を参照してください。

ユーザーが以前に、プラットフォームの他の部分とは異なるポータルのユーザーエクスペリエンスアナリティクスのユーザーの同意設定を選択した場合、プラットフォーム用に選択された設定は Washington DC リリースのポータルにも使用されます。たとえば、ユーザーがポータルの追跡をオプトアウトし、Vancouver リリースではプラットフォームの残りの部分の追跡をオプトインした場合、ポータルのユーザーエクスペリエンスアナリティクスは Washington DC リリースで追跡されます。ユーザーは、ポータルのユーザープロファイルページからいつでも選択内容を更新できます。

Washington DC

ソフトウェア資産管理

Washington DC にアップグレードした後は、Adobe に関連するすべてのカスタマイズや ServiceNow インスタンスとの Microsoft 365 統合をやり直す必要があります。これらの統合の機能がソフトウェア資産管理 – SaaS ライセンス管理ストアアプリケーションに移動されるためです。

影響を受けるファイルをカスタマイズした場合、アップグレードプロセスはファイルをスキップし、競合を示します。競合を手動で解決し、古い既存のファイルが削除されていることを確認する必要があります。
影響を受けるファイルをカスタマイズしていない場合、ファイルはアップグレードの一部として削除され、新しい sys_id を含むファイルが作成されます。

Washington DC

戦略的計画

v4.0.2 以降、戦略的ポートフォリオ管理 (SPM) Pro ライセンス機能には、戦略的計画ワークスペースでのみアクセスできます。ポートフォリオ計画ワークスペースを使用して、SPM Pro ライセンスの機能 (目標、製品フィードバック、ハイブリッドポートフォリオ計画など) にアクセスしている場合、そのような機能にアクセスするには Strategic Planning をインストールする必要があります。戦略的計画ワークスペースでのみアクセスできる機能の詳細については、「戦略的計画におけるポートフォリオ計画」を参照してください。

戦略的計画 v4.1.2 にアップグレードしていて、以前にパーソナライズサイドパネルを使用して [ゴール] ページのリストビューまたは階層ビューをカスタマイズしていた場合、v4.1.2 で行われたユーザーインターフェイスの拡張機能が表示されないことがあります。この場合、ユーザー設定レコードを削除する必要があります。パーソナライズサイドパネルを使用して作成したユーザー設定を削除する方法の詳細については、KB1642037 を参照してください。

Washington DC

サプライヤーライフサイクルオペレーション

Vancouver リリースから Washington DC リリースにアップグレードすると、[すべて] ナビゲーションタブの Source-to-Pay ワークスペースのみが表示されます。Source-to-Pay ワークスペースを引き続き使用することを選択した場合は、何もする必要はありません。

ただし、[ワークスペース] タブには、Source-to-Pay ワークスペースとサプライヤーマネージャーワークスペースの両方が表示されます。デフォルトの Source-to-Pay ワークスペースの代わりにサプライヤーマネージャーワークスペースを使用する場合は、Washington DC リリースにアップグレードした後に fixscript_migrate_workspace_to_smw.xml 修正スクリプトを実行してください。fixscript_migrate_workspace_to_smw.xml ファイルは ServiceNow Store からダウンロードできます。

Source-to-Pay ワークスペースを再び使用する場合は、fixscript_migrate_workspace_to_s2p.xml 修正スクリプトを実行します。fixscript_migrate_workspace_to_smw.xml ファイルは ServiceNow Store からダウンロードできます。修正スクリプトの実行方法の詳細については、「修正スクリプトの実行」を参照してください。

Washington DC にアップグレードした後、アップグレード後のすべてのタスクを確認し、必要に応じて完了する必要があります。詳細については、「Post-upgrade tasks for Supplier Lifecycle Management (サプライヤーライフサイクル管理のアップグレード後のタスク)」を参照してください。

Washington DC

脆弱性対応統合

脆弱性対応アプリケーションのリリース済みバージョンと、Washington DC リリースと互換性のあるサードパーティアプリケーションや ServiceNow アプリケーションについて詳しくは、Now Support ナレッジベース記事「Vulnerability Response Compatibility Matrix and Release Schema Changes (脆弱性対応互換性マトリクスおよびリリーススキーマの変更点) [KB0856498]」を参照してください。
脆弱性対応の新機能の詳細については、「脆弱性対応リリースノート」を参照してください。

Washington DC

ワークフロースタジオ

ワークフロースタジオのパフォーマンスを改善するには、ServiceNow Store からこれらのバージョンのワークフロースタジオアプリケーションのいずれかをインストールします。

表 : 9. フロー生成スキルのアップグレードパス
クリエーターの Now Assist は既にインストールされていますか？	アップグレードに使用するワークフロースタジオのバージョン
いいえ	ワークフロースタジオをバージョン 25.1.3 にアップグレード
はい	ワークフロースタジオをバージョン 25.0.0 にアップグレード

Washington DC

AI 検索

以前のリリースから Xanadu にアップグレードした後、次の手順を実行して、ネクストエクスペリエンス向け AI 検索のグローバル検索結果にダッシュボード、データ可視化、および KPI ナビゲーションタブを追加します。

ネクストエクスペリエンス向け AI 検索 ServiceNow Store アプリケーションをバージョン 4 以降に更新します。更新手順については、「ServiceNow Store アプリケーションをインストールまたは更新する」を参照してください。
Now Support ナレッジベースの「ネクストエクスペリエンス向け AI 検索 4.0 PAR テーブル更新セット (KB1644544)」記事で提供されている更新セットをコミットします。更新セットの詳細については、「システムアップデートセット」を参照してください。

Xanadu

買掛金オペレーション

以前のリリースからアップグレードする場合は、参照フィールドの税コード [sn_fin_tax_code] テーブルを構成する必要があります。例外エンジンは税コードを使用して請求書を検証し、必要に応じて例外を発生させます。

Xanadu

アナリティクス、インテリジェンス、レポート

アップグレードする場合は、プラットフォームアナリティクス移行センターを使用して、すべてのデータソースに対して単一の可視化セットと統合フィルターを利用できます。

Xanadu

App Engine Studio

App Engine 管理センター (AEMC) でグループをアサインする新しいプロセスにより、各インスタンスに同じバージョンのアプリケーション取り込みプラグインがインストールされていることを確認してください。

Xanadu

アプリケーション脆弱性対応

脆弱性対応の新機能の詳細については、「脆弱性対応リリースノート」を参照してください。
アプリケーション脆弱性対応アプリケーションのリリース済みバージョンと、Xanadu リリースと互換性のあるサードパーティアプリケーションや ServiceNow アプリケーションについて詳しくは、Now Support ナレッジベース記事「Vulnerability Response Compatibility Matrix and Release Schema Changes (脆弱性対応互換性マトリクスおよびリリーススキーマの変更点) [KB0856498]」を参照してください。

Xanadu

事業継続性管理

計画レコードに導入された関係テーブルは、Update BCP dependencies snapshot スケジュール済みジョブによって生成されます。Xanadu リリースにアップグレードした後は、スケジュール済みジョブが実行された後、または [依存関係を更新 (Update dependencies)] ボタンを手動で選択した後にのみ、これらのテーブルを表示できます。

Xanadu

CSM のケース管理

カスタマーサービスマネージャーロール [sn_customerservice_manager] には、承認者ユーザーロール [approver_user] が含まれています。承認者ユーザーロールは、承認アドミンロール [approval_admin] に置き換わります。カスタマーサービスマネージャーロールを持つユーザーは、自分にアサインされた承認要求を承認できます。

Xanadu

クラウドコスト管理 8.0.0

クラウドコスト管理 8.0 バージョンにアップグレードすると、Amazon Web Services (AWS)、Microsoft Azure、および Google Cloud Platform (GCP) サービスプロバイダーに対して、新しいタグカテゴリ [AI サービス] を利用できるようになります。クラウドコスト管理では、請求処理ダウンロードジョブは当月以降のみ実行されるため、AI サービスへの支出は当月分のみが含まれます。当月より前の月の請求の詳細を表示する場合は、請求処理ダウンロードジョブを手動で実行する必要があります。請求処理ダウンロードジョブが正常に実行されると、AI サービスの支出データを表示できます。

Xanadu

構成管理データベース (CMDB)

Xanadu にアップグレードする前は、CMDB ワークスペースの管理ビューの [最近の CI アクティビティ] および [最近のアプリケーションサービスアクティビティ] タイルの [更新された CI] および [更新されたアプリケーションサービス] 傾向ラインが、システムの変更を正確に反映していない可能性がありました。Xanadu および CMDB ワークスペースのバージョン 5.5、6.2、または 7.2 にアップグレードすると、これらの傾向ラインは、更新された CI と更新されたアプリケーションサービスのより正確な検出に反映されます。
CMDB ヘルス：
CMDB Health Dashboard - Relationship Compliance Processor または CMDB Health Dashboard - Relationship Score Calculation ダッシュボードジョブのいずれかがアクティブな場合、Xanadu へのアップグレード中にそのジョブは非アクティブ化されます。アップグレードが完了したら、これらのジョブを再アクティブ化して、CI 関係のヘルスレポートを再開できます。他のすべての CMDB ヘルスダッシュボードジョブのアクティブ状況は保持されます。
100,000 を超える KPI または測定基準の失敗しきい値は、アップグレード中に 100,000 に設定されます。この上限は、多数の CI が指定された測定基準テストに失敗した場合に過剰な処理を避けるために適用されます。
Xanadu にアップグレードすると、CI ダッシュボードのブックマークは機能しなくなります。「ページが見つかりません」というエラーメッセージが表示されます。CI の CMDB ヘルスレポートを表示するには、CMDB ワークスペースで CI フォームを開きます。
コア UI の従来のアプリケーションサービスダッシュボードは、Xanadu リリースではサポートされていません。アップグレード後も、以前に作成したブックマークを使用して、その従来のダッシュボードに引き続きアクセスできます。代わりに、CMDB ワークスペースのインサイトビューにある [アプリケーションサービス] タイルから CMDB ワークスペースのアプリケーションサービスダッシュボードにアクセスすることもできます。
コア UI の CMDB 統合ダッシュボードは、Xanadu リリースではサポートされていません。アップグレード後も、以前に作成したブックマークを使用して、その従来のダッシュボードに引き続きアクセスできます。

アップグレードされたインスタンスの従来のダッシュボードにアクセスするには、[すべて] > [セルフサービス] > [ダッシュボード]に移動し、ダッシュボードを検索します。

Xanadu

データ管理

アップグレード前にアーカイブルールまたはテーブルクリーナールールが構成されているテーブルごとに、データ管理ポリシーレコードが自動的に作成されます。

Xanadu

ワークフロースタジオのディシジョンテーブル

ワークフロースタジオはインスタンスに自動でインストールされます。ただし、ワークフロースタジオは ServiceNow Store アプリケーションであるため、最新の機能を取得するには、バージョンを最新バージョンに更新する必要があります。Washington DC パッチ 3 時点では、ワークフロースタジオを更新すると、ワークフロースタジオ、プレイブック、ディシジョンビルダーなどのすべてのアプリケーション依存関係が自動的に更新されます。ServiceNow Store またはプラグインのリストから、ワークフロースタジオの個々のアプリケーション依存関係を表示または更新することはできなくなりました。

Xanadu

ワークフロースタジオのフロー、サブフロー、およびアクション

アップグレード後、以前に fd_read_operations ロールを持っていたユーザーには、実行ステータスや期間などの基本的な実行の詳細のみが表示されるようになりました。この制限により、このロールを持つユーザーは実行の詳細で機密情報を表示できなくなります。入力構成やランタイム値などのすべての実行の詳細への読み取りアクセス権を付与するには、ユーザーに新しいロール fd_read_operations_all を付与します。

Xanadu

ハードウェア資産管理 11.0.0

Xanadu にアップグレードすると、ハードウェア資産管理のコア UI パフォーマンスアナリティクスダッシュボードとネクストエクスペリエンスプラットフォームアナリティクスダッシュボードの両方を表示できます。

注:

コア UI パフォーマンスアナリティクスダッシュボードをネクストエクスペリエンスプラットフォームアナリティクスダッシュボードに移行する際、ダッシュボードの重複を避けるために、自動移行はデフォルトで無効になっています。

Xanadu

ITOM ヘルス

ServiceNow® Store から App Service Extension アプリをインストールして、アプリケーションサービスマッピングを拡張します。

Xanadu

ITOM 最適化

ServiceNow® Store から App Service Extension アプリをインストールして、アプリケーションサービスマッピングを拡張します。

Xanadu

ITOM Visibility (ITOM ヴィジビリティ)

サービスマッピングのエクスペリエンスを向上させるには、ServiceNow® Store からサービスマッピング Plus バージョン 13.0 をインストールします。

ServiceNow® Store から App Service Extension アプリをインストールして、アプリケーションサービスマッピングを拡張します。

サービスマッピング Plus の顧客は、ServiceNow® Store から App Service Extension アプリをインストールして、アプリケーションサービスマッピングを拡張します。

Xanadu

産業用プロセスマネージャー

オペレーショナルテクノロジーヴィジビリティ SKU
Operational Technology Service Management SKU
産業用プロセスマネージャーの資格を付与するカスタム SKU

Xanadu

MID サーバー

独自の JRE をインストールしている場合、サポートされている JRE を MID サーバーが使用することを検証するために、アップグレードプロセスでは次のアクションが実行されます。

アップグレードの際に MID サーバーがサポートされていないバージョンの JRE を使用している場合、アップグレードプロセスで JRE の最低バージョンと推奨バージョンを示す警告メッセージが表示されます。
サポートされている JRE が MID サーバーホストで実行されている場合、アップグレードされた MID サーバーはそのバージョンを使用します。

実行可能ファイルパスに従って、Windows MID サーバーサービスは 1 つのみ許可されます。アップグレードした Windows MID サーバーに同じインストールフォルダーを指しているサービスが複数ある場合は起動できません。詳しくは「MID Server fails to start (MID サーバーが起動しない)」を参照してください。

MID サーバーのアップグレードについて詳しくは次のトピックを参照してください。

MID サーバーのアップグレード前のチェック：実際にアップグレードを行なう前に、システムでの MID サーバーのアップグレード機能を AutoUpgrade モニターでテストする方法を説明しています。
手動での MID サーバーのアップグレード：MID サーバーを手動でアップグレードする方法について説明しています。

Xanadu

Security Operations の Now Assist

アプリケーションを実装するための要件のリストについては、「Security Operations の Now Assist のサポート情報」を参照してください。

Xanadu

Now Assist

Now Assist スキルに関連付けられている UI アクションまたはその他のアイテムをカスタマイズした場合は、カスタマイズしたコードが新しいスキルリリースで更新されていることを確認してください。そうしないと、特定の機能が期待どおりに機能しない可能性があります。

Now Assist 製品のアップグレード中に問題が発生した場合は、「KB1637452：Now Assist (生成 AI) アプリケーションおよびプラグインの更新の問題と軽減策」を参照してください。記事を表示するにはログインする必要があります。

Xanadu

プラットフォームアナリティクスエクスペリエンス

新規顧客：プラットフォームアナリティクスエクスペリエンスは、Now Platform で自動的に利用可能になります。直感的なインターフェイスを提供し、データをよりよく理解して活用するのに役立ちます。

アップグレードする顧客：現在コア UI のレスポンシブダッシュボードを使用している場合は、中断することなく引き続きアクセスできます。新機能を最大限に活用するには、プラットフォームアナリティクスエクスペリエンスへの移行を検討してください。

Xanadu

ワークフロースタジオのプレイブック

Xanadu にアップグレードした後、ServiceNow Store のプレイブックおよびワークフロースタジオアプリケーションを更新します。

Xanadu

公共機関デジタルサービス

Xanadu

RPA Hub

RPA アプリケーションをダウンロードして、現在インストールされている Microsoft ソフトウェアインストーラー (MSI) をアップグレードしてください。

RPA デスクトップデザインスタジオ
アテンド型ロボット
無人ロボット
無人ロボットログインエージェント

詳細については、「Download the RPA applications from RPA Hub (RPA ハブからの RPA アプリケーションのダウンロード)」を参照してください。

次のアップグレード情報は、San Diego または Tokyo から Xanadu にアップグレードする場合にのみ適用されます。

アプリケーションファイルテーブル内のレコード数に応じて、RPA Hub アプリケーションの Tokyo 以前のリリースから Xanadu へのアップグレードに遅延が生じる可能性があります。

RPA Hub を Xanadu にアップグレードする前に、glide.rollback.blacklist.TableParentChange.change システムプロパティの値を false に設定する必要があります。このプロパティがシステムプロパティ [sys_properties] テーブルに存在しない場合は、プロパティを追加し、その値を false に設定します。プロパティの追加方法の詳細については、「システムプロパティを追加する」を参照してください。

Xanadu にアップグレードすると、ボットプロセス定義は新しい構造、つまりボットプロセス構成に変更されます。

ボットプロセス構成がボットプロセスを完全に置き換えるわけではありませんが、ほとんどのフィールドはボットプロセスからボットプロセス構成に移動されます。システムプロパティ値を更新せずに Xanadu にアップグレードすると、テーブルは [アプリケーションファイル (Application File)] テーブルを拡張しません。テーブルの変更を手動で更新するには、Now Support ナレッジベースの記事「Restructuring RPA Hub tables to sys_metadata in Utah and beyond release (Utah 以降のリリースの sys_metadata への RPA Hub テーブルの再ビルド)」を参照してください。

Xanadu

セキュリティインシデントレスポンス

該当なし

Xanadu

セキュリティポスチャコントロール

セキュリティポスチャコントロールの実装に必要なアプリケーションの完全なリストについては、「セキュリティポスチャコントロールのインストール」を参照してください。

Xanadu

サービスブリッジ

Xanadu リリースでリリースされるサービスブリッジ 2.x.x は、サービスブリッジ (レガシー) バージョンの移行をサポートしていません。サービスブリッジ (レガシー) バージョンを使用している場合は、Xanadu リリースにアップグレードする前に、Now Support ナレッジベース記事「Service Bridge for Providers (Legacy) - Migration Utility (KB1499823) (プロバイダー向けサービスブリッジ (レガシー) - 移行ユーティリティ)」の手順に従って構成データを移行する必要があります。
不一致バージョンのサポートの導入により、コンシューマーとプロバイダーの両方が Xanadu リリースにアップグレードするまで、新しいエンタイトルメントはアクティブ化できません。古いアクティブなエンタイトルメントは引き続き機能しますが、新しいエンタイトルメントはアクティブ化できません。

Xanadu

Service Operations Workspace for ITSM

次のアプリケーションに互換性のあるアップグレードバージョンが存在することを確認します。

サービスオペレーションワークスペース ITSM Applications アプリケーション (sn_sow_itsm_cont)
サービスオペレーションワークスペース ITOM アプリケーション (sn_sow_itom_cont)

表 : 10. 互換性のあるサービスオペレーションワークスペースバージョン
Service Operations Workspace for ITSM (sn_sow_itsm_cont)	ITOM のサービスオペレーションワークスペース (sn_sow_itom_cont)
1.1.x	21.0.y
1.2.x	21.1.y
1.3.x	21.2.y、21.5.y、および 21.6.y
2.0.x	22.0.y
2.1.x	22.1.y および 22.y.y
3.1.x	23.y.y
4.x.x	24.y.y
5.0.x	24.2.y

Xanadu

ServiceNow SDK

now-sdk upgrade コマンドを使用して、ServiceNow SDK の最新バージョンにアップグレードします。詳細については、「ServiceNow SDK のアップグレード」を参照してください。

Xanadu

スキル管理

スキルダッシュボードは、Xanadu リリースでネクストエクスペリエンス UI に自動的に移行されます。アップグレードすると、ネクストエクスペリエンス UI のスキルダッシュボードに自動的にアクセスできるようになります。

Xanadu

ソフトウェア資産管理

Microsoft Entra ID スポーク 4.3 バージョンにアップグレードすると、既存の Microsoft Azure AD SSO またはディレクトリ統合に対して Microsoft Azure AD - Download Group Membership ディレクトリジョブは実行されません。このディレクトリジョブは、新しい Microsoft Azure AD SSO またはディレクトリ統合用にも作成されません。代わりに、Microsoft Azure AD - Download Groups ディレクトリジョブは、Microsoft Azure AD で構成されているすべてのグループとグループメンバーシップをダウンロードします。

Xanadu

通信事業ネットワークインベントリ

以前のリリースの既存ユーザーである場合は、Xanadu にアップグレードすると、従来の製品モデルと新しい製品モデルの両方が [ネットワークインベントリワークスペース] メニューで使用できるようになります。この問題を修正するには、従来の製品モデルのデータを現在のインスタンスの新しい製品モデルのテーブルに移行する必要があります。この手順の詳細については、「KB1695167」を参照してください。

Xanadu

ワークフロースタジオ

Washington DC パッチ 3 では、ワークフロースタジオを更新すると、 ServiceNow® ワークフロースタジオ、プレイブック、 ServiceNow® ディシジョンビルダーなどのすべてのアプリケーション依存関係が自動的に更新されます。ServiceNow® Store またはプラグインのリストから、ワークフロースタジオの個々のアプリケーション依存関係を表示または更新することはできなくなりました。

Xanadu