様々な製品に関するアップグレード前後のタスク
アップグレードの準備として、さまざまなアプリケーションや機能のアップグレードおよび移行のタスクを確認します。該当する場合は、アップグレード完了前後でそれらのタスクを完了する計画を立てます。
スムーズなアップグレードのためのインスタンスの準備
Washington DC にアップグレードする前に、これらのアップグレード前後のタスクを確認し、必要に応じて完了してください。
アップグレードおよび移行のタスク
| 製品 | リリースノート | ファミリ | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
AI Search | Quebec または Rome から San Diego にアップグレードすると、AI Search がインデックス付け済みのすべての日本語コンテンツに自動的にインデックスを再作成します。この 1 回限りの再インデックス付けプロセスは、このリリースで日本語の検索エクスペリエンスの改善を有効にするために必要です。 Quebec または Romeで Q&A Genius 結果を有効にした場合は、San Diego にアップグレードした後に ナレッジコンテンツのインデックスを再作成する必要があります。この 1 回限りのインデックス再作成プロセスは、このリリースで Q&A の改善を有効にするために必要です。 | San Diego | ||||||||||||||||||||
アプリケーション使用状況の概要ダッシュボード | San Diego リリースにアップグレードした後は、[アプリケーション使用状況の概要] ホームページは編集できません。 | San Diego | ||||||||||||||||||||
アセスメントとサーベイ | Assessments and Surveys を San Diegoにアップグレードした後、廃止されたサーベイユーザー招待メール通知を非アクティブ化します。その後、新しいメール通知である [サーベイへの招待] をアクティブ化します。 | San Diego | ||||||||||||||||||||
Automated Test Framework | Now Platform®で提供されているクイックスタートテストをコピーしカスタマイズして、構成変更後もインスタンスが動作することを検証します。たとえば、アップグレードを適用するか、アプリケーションを開発する場合です。 カスタマイズを行っていないベースシステム上で、アプリケーションまたは機能プラグインが提供するデフォルトのデモデータを使用してテストを実行した場合にのみ、テストで合格の結果を生成できます。インスタンス固有のデータにクイックスタートテストを適用するには、クイックスタートテストをコピーしてカスタムデータを追加します。詳しくは、「Available quick start tests by application or feature (アプリケーションおよび機能別に利用可能なクイックスタートテスト)」を参照してください。 ATF は、Next Experience の特定の要素をサポートしていません。詳細については、「Automated Test Framework」を参照してください。 | San Diego | ||||||||||||||||||||
Business Continuity Management |
| San Diego | ||||||||||||||||||||
Cloud Insights | 手順については、「Upgrade to version 2.2 (Cloud Insights バージョン 2.2 へのアップグレード)」を参照してください。 | San Diego | ||||||||||||||||||||
Configuration Compliance |
| San Diego | ||||||||||||||||||||
Core Now Platform | アップグレード後、ServiceNow の担当者にインスタンスの設定を要求して、ServiceNow が言語プラグインを提供している 22 言語以外の言語をサポートすることができます。2 文字の言語コードは BCP 47 標準をサポートしています。 JavaScript エンジンのデフォルトの式評価モードがコンパイル済みモードから解釈済みモードに変更されました。詳細については、KB0960944 を参照してください。 sys_archive_log に 1,000 万件を超えるレコードがある場合は、sys_archive_log に (archive、restored) および (archive、sys_created_on、restored、from_table) インデックスを追加します。
注: sys_archive_log のレコード数が 1,000 万未満の場合、アップグレードには問題がありません。列の順序は (archive、restored) および (archive、sys_created_on、restored、from_table) と正確に一致している必要があります。San Diego のアップグレード前に、適切な列が sys_archive_log テーブルに既に存在する場合は、UI を使用してこれを実行できます。
| San Diego | ||||||||||||||||||||
DevOps | 注: San Diego での DevOpsアプリケーションのすべての新規インストールでは、com.snc.change_management.change_model.type_compatibility プロパティを True に設定する必要があります。バージョン 1.31 にアップグレードするには、 ServiceNow Store から DevOps Change Velocity アプリを検索してインストールします。
| San Diego | ||||||||||||||||||||
暗号化とキー管理 | San Diego へのアップグレード時に、暗号化コンテキストは Column Level Encryption フィールド暗号化モジュールおよび対応するモジュールアクセスポリシーに自動的に変換されます。この機能拡張について説明するチュートリアルをダッシュボードから利用できます。 | San Diego | ||||||||||||||||||||
Governance, Risk, and Compliance | Governance, Risk, and Compliance バージョン14.0 以降では、GRC ロールを持つユーザーのみが GRC レコードにアクセスできます。snc_internal ロールを持つユーザーがアクセスできたレコードは、GRC ロールを持つユーザーのみがアクセス可能となりました。詳細については、 Now Support ナレッジベースの「Security tightening for GRC apps (GRC アプリのセキュリティ強化) [KB1096145]」を参照してください。 | San Diego | ||||||||||||||||||||
Health Log Analytics | San Diego にアップグレードする場合は、Now Support から Health Log Analytics アプリケーションのコアコンポーネントのアップグレードを要求するか、ServiceNow の営業担当者にお問い合わせください。 | San Diego | ||||||||||||||||||||
MID Server | 最新のMID Server システム要件については、「MID Server system requirements (MID Server システム要件)」を参照してください。次の Java Runtime Environment (JRE) バージョンがサポートされています。
自動アップグレードを行なうには、すべての MID Server ホストマシンが install.service-now.com のダウンロードサイトにアクセスする必要があります。詳細については、「How the System Manages MID Server Upgrades (システムが MID Server アップグレードを管理する方法)」をご確認ください。 1つの実行可能ファイルパスにつき、 Windows MID Server サービスは1つのみ許可されます。アップグレードした Windows MID Servers に同じインストールフォルダーを指しているサービスが複数ある場合は起動できません。詳しくは『MID Server fails to start (MID Server が起動しない)』を参照してください。 MID Server のアップグレードについて詳しくは次のトピックを参照してください。
| San Diego | ||||||||||||||||||||
モバイル | ServiceNow クラシックモバイルプラットフォームから ServiceNow モバイルプラットフォームに移行して、迅速な開発、オフライン機能、ネイティブモバイルデバイス機能との統合などの機能を活用します。ServiceNow モバイルプラットフォームへの移行の詳細については、「Migrate from the ServiceNow Classic mobile app to the ServiceNow Mobile Platform (ServiceNow クラシックモバイルアプリから ServiceNow モバイルプラットフォームへの移行)」を参照してください。 | San Diego | ||||||||||||||||||||
Next Experience UI |
| San Diego | ||||||||||||||||||||
Order Management for Telecommunications, Media, and Technology | Order Management for Telecommunications, Media, and Technology アプリケーションをサポートするテーブルアーキテクチャが再構築されました。San Diego リリースにアップグレードした後、Order Management for Telecommunications, Media, and Technology を使用する前に、既存の注文データを新しく再構築されたテーブルに移動するスクリプトを最初に実行する必要があります。詳細については、Now Support ナレッジベース記事「Order Management for Telecommunications, Media, and Technology (2.0.0) version: Post upgrade reparenting script for the San Diego release (Order Management for Telecommunications, Media, and Technology (2.0.0) バージョン： San Diego リリース用アップグレード後の親再指定スクリプト [KB1000941]」を参照してください。 | San Diego | ||||||||||||||||||||
Performance Analytics | データコレクションジョブの条件付きスクリプトは、権限が制限されたサンドボックスで実行されるようになりました。この変更により、既存の条件付きスクリプトでスクリプト実行エラーが発生する場合があります。スクリプト化されたデータコレクションジョブがある場合は、非本番ビルドでアップグレードをテストすることを検討してください。必要に応じてスクリプトを書き換えます。詳細については、「Script sandbox property (スクリプトサンドボックスプロパティ)」を参照してください。 | San Diego | ||||||||||||||||||||
Privacy Management | San Diego リリースで Privacy Management を使用できるようにするには、Advanced Risk プラグインをアクティブ化する必要があります。 | San Diego | ||||||||||||||||||||
Reporting | スケジュール済みレポートジョブの条件付きスクリプトは、権限が制限されたサンドボックスで実行されるようになりました。この変更により、既存の条件付きスクリプトでスクリプト実行エラーが発生する場合があります。スクリプト化されたスケジュール済みレポートジョブがある場合は、非本番ビルドでアップグレードをテストすることを検討してください。必要に応じてスクリプトを書き換えます。詳細については、「Script sandbox property (スクリプトサンドボックスプロパティ)」を参照してください。 | San Diego | ||||||||||||||||||||
Security Incident Response | Security Incident Response を以前のリリースから直接アップグレードする場合は、次の場所に移動します をクリックし、「 統合をマルチドメインに更新 」修正スクリプトを実行します。このスクリプトを実行して、特定の統合で複数の構成を定義できるようにします。 たとえば、複数の Splunk インスタンスがある場合は、複数の Splunk インスタンスのサイティング検索全体で実行する接続とクエリを作成できます。修正スクリプトを実行した後、次に移動します。 修正スクリプトを無効化できますスクリプトは複数回実行しないでください。 | San Diego | ||||||||||||||||||||
Service Catalog | San Diego にアップグレードし、サービス遂行手順を実行するために必要な情報を保存するようにデータストアを設定する場合は、拡張するサービス遂行手順 [sc_service_fulfillment_step] テーブルで canCreate、canUpdate、canRead のアプリケーションアクセスが有効になっていることを確認してください。 San Diego にアップグレードし、要求に対して新しいメール通知テンプレートを使用する場合は、それらをアクティブ化する必要があります。詳細については、「Email notifications for requests (要求に関するメール通知)」を参照してください。 San Diego にアップグレードしていて、ビジネスステークホルダーとして要求アイテムにコメントを追加する場合は、[スクリプト - バックグラウンド] モジュールの | San Diego | ||||||||||||||||||||
Service Operations Workspace for ITSM | 次のアプリケーションに互換性のあるアップグレードバージョンが存在することを確認します。
ここで、x は Service Operations Workspace ITSM Applications アプリケーション (sn_sow_itsm_cont) のサブバージョンで、y は Service Operations Workspace ITOM Applications アプリケーション (sn_sow_itom_cont) のサブバージョンです。 | San Diego | ||||||||||||||||||||
ServiceNow パフォーマンスダッシュボード | San Diego にアップグレードすると、パフォーマンスホームページを編集できなくなります。 | San Diego | ||||||||||||||||||||
ServiceNow 音声アシスト機能 | アップグレード後、ラベル名の変更がテーブルに表示されます。
| San Diego | ||||||||||||||||||||
Software Asset Management | Software Asset Management Foundation プラグイン (com.snc.sams) のアップグレードについて詳しくは、「Revert Software Asset Management Customizations (Software Asset Management のカスタマイズを元に戻す)」を参照してください。 追加のアップグレード情報については、「Software Asset Management アップグレード情報」を参照してください。 | San Diego | ||||||||||||||||||||
Store 使用率の概要ダッシュボード | San Diego にアップグレードした後は、ServiceNow Store 使用率の概要ホームページを編集できなくなります。 | San Diego | ||||||||||||||||||||
システム管理者ダッシュボード | San Diego リリースにアップグレードした後は、システム管理者ホームページを編集できなくなります。 | San Diego | ||||||||||||||||||||
システム診断ホームページ | San Diego にアップグレードした後は、システム診断ホームページを編集できなくなります。 | San Diego | ||||||||||||||||||||
仮想エージェント |
| San Diego | ||||||||||||||||||||
Vulnerability Response integrations |
| San Diego | ||||||||||||||||||||
Vulnerability Response |
Vulnerability Response アプリケーションを古いバージョンからバージョン 15.x にアップグレードすると、ベースシステムのデフォルトの修正タスクルールが非アクティブ化されます。詳細については、「Vulnerability Response Workspaces and updates to remediation task and remediation task rules (Vulnerability Response のワークスペースおよび、修正タスクと修正タスクルールの更新)」を参照してください。 | San Diego | ||||||||||||||||||||
Walk-up Experience | 以前のリリースを使用している場合は、San Diegoへのアップグレードを開始する前に、現在のインスタンスを構成する必要があります。Microsoft Teams チャットを使用してリモート Walk-up 予約を強化する場合は、「Microsoft Teams データ連携」を参照してください。統合により、Skills Management プラグイン (com.snc.skills_management) と Skills Determination プラグイン (com.snc.skill_determination) がアクティブ化されます。 | San Diego | ||||||||||||||||||||
Workforce Optimization for ITSM | Workforce Optimization for ITSM バージョン 1.1.1 にアップグレードする場合は、次のテーブルのテキストインデックス作成を有効にする必要があります。
| San Diego | ||||||||||||||||||||
AI Search | 以前のリリースから Tokyo にアップグレードすると、AI Search は、カタログアイテム [sc_cat_item] テーブルおよびナレッジ [kb_knowledge] テーブルのインデックス付きソースからコンテンツとメタデータに自動的にインデックスを再作成します。この 1 回限りのインデックス再作成プロセスは、このリリースで検索エクスペリエンスを改善するために必要です。 以前のリリースから Tokyo にアップグレードした後に検索アプリケーション構成を表示または編集すると、1 つ以上のインデックス付きソースを再インデックス付けするように指示する警告メッセージが表示される場合があります。このインデックス再作成プロセス (リストされているインデックス付きソースごとに 1 回限りのプロセス) は、検索ベースのオートコンプリート候補を正しく入力するために必要です。 以前のリリースから Tokyo にアップグレードすると、検索結果のデフォルトの関連性スコアが変更される場合があります。以前のリリースでトレーニングされた関連性モデルは、引き続き同じ結果の順序を生成します。複数のリリース前にトレーニングされたモデルは、デフォルトの関連性モデルに戻る可能性があります。 AI Search report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、 Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。 | Tokyo | ||||||||||||||||||||
Admin Center | Admin Center アプリケーションの最新バージョンは、ServiceNow Store で入手できます。 | Tokyo | ||||||||||||||||||||
Application Portfolio Management | Application Portfolio Management report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、 Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。 | Tokyo | ||||||||||||||||||||
アセスメントとサーベイ | 以前のリリースから Tokyo にアップグレードすると、Service Portal と Now Mobile アプリで Assessments and Surveys がデフォルトでアクティブ化されます。 | Tokyo | ||||||||||||||||||||
Automated Test Framework | 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 | ||||||||||||||||||||
Configuration Compliance |
| Tokyo | ||||||||||||||||||||
Conversational Interfaces のホーム | Conversational Interfaces のホームは 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 のアクセス制御)」を参照してください。 | 東京 | ||||||||||||||||||||
Customer Service Management (CSM) | Customer Service Management report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、 Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。 | Tokyo | ||||||||||||||||||||
Employee Journey Management | HR Service Delivery report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、 Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。 | Tokyo | ||||||||||||||||||||
暗号化キー管理 | 暗号化コンテキストは、San Diego リリース以降へのアップグレード時に、Column Level Encryption フィールド暗号化モジュールおよび対応するモジュールアクセスポリシーに自動的に変換されます。この機能拡張について説明するチュートリアルをダッシュボードから利用できます。 暗号化キー管理 report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、 Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。 | Tokyo | ||||||||||||||||||||
Flow Designer | Flow Designer report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、 Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。 San Diego およびそれ以前のリリースからアップグレードしたインスタンスが、フローとアクションに対する制限付き呼び出し元アクセス権限要求を生成できるようにすることができます。フローとアクションのアクセス権限を有効にする方法の詳細については、「Upgrade restricted caller access privileges for flows and actions (フローとアクションに対する制限付き呼び出し元アクセス権限のアップグレード)」を参照してください。
警告: フローとアクションを追跡するように制限付きの申請者アクセス特権をアップグレードすると、以前はスクリプトインクルードやビジネスルールからのクロススコープアクセスを追跡していたインスタンスで、サービスが中断される可能性があります。アップグレード後は、制限付きリソースへのアクセスを試みるすべてのフローとアクションの実行がブロックされ、代わりにそのフローやアクション独自の制限付きの申請者アクセス特権に対する承認要求が生成されます。クロススコープのフローおよびアクションを実行するには、アクセス権限要求を誰かが承認する必要があります。スクリプトの呼び出しを使用してフローとアクションの間接的な追跡を既に許可しているお客様は、このタスクをスキップして、引き続きスクリプトからフローとアクションを呼び出すことができます。既存のアクセス権限を新しいフローおよびフローアクションのソースタイプに置き換えたいお客様は、新しいアクセス権限要求を生成および承認するための機能停止のスケジュールを設定することができます。 | Tokyo | ||||||||||||||||||||
Governance, Risk, and Compliance | Governance, Risk, and Compliance バージョン 14.0 以降、ビジネスユーザー (sn_grc.business_user) ロールは GRC リーダー (sn_grc.reader) ロールから削除され、GRC ユーザー (sn_grc.user) ロールに追加されます。詳細については、KB1123608 を参照してください。 | Tokyo | ||||||||||||||||||||
HR Service Delivery Case and Knowledge Management | HR Service Delivery report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、 Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。 | Tokyo | ||||||||||||||||||||
Health Log Analytics | Health Log Analytic のバージョンが 2022 年 2 月より前の場合は、Now Support または ServiceNow 営業担当者に連絡して、Health Log Analytics アプリケーションコアコンポーネントのアップグレードを要求してください。 | Tokyo | ||||||||||||||||||||
ITOM Visibility | ITOM Visibility 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 | ||||||||||||||||||||
ID と認証 | ID と認証 report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、 Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。 | Tokyo | ||||||||||||||||||||
インポートとエクスポート | インポートとエクスポート report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、 Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。 | Tokyo | ||||||||||||||||||||
Incident Management | Incident Management report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、 Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。 | Tokyo | ||||||||||||||||||||
Instance Data Replication | Instance Data Replication 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 | ||||||||||||||||||||
Integration Hub | Integration Hub report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、 Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。 | Tokyo | ||||||||||||||||||||
Intelligent Service Delivery | HR Service Delivery report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、 Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。 | Tokyo | ||||||||||||||||||||
Knowledge Management |
| Tokyo | ||||||||||||||||||||
Legal Service Delivery | Legal Service Delivery を Tokyo にアップグレードする前に、glide.rollback.blacklist.TableParentChange.change システムプロパティの値を false に設定する必要があります。このプロパティがシステムプロパティ [sys_properties] テーブルに存在しない場合は、プロパティを追加し、その値を false に設定します。 アップグレード後、Legal Request Management、Legal Digital Forensics、Legal Simple Contracts の各アプリケーションでインストールされた一部のテーブルは、アプリケーションファイル [sys_metadata] テーブルを拡張して、実務エリア、問診票フォーム、契約構成、フォレンジック構成を更新セットにシームレスに移行できるようにします。 システムプロパティ値を更新せずに Tokyo バージョンにアップグレードすると、テーブルはアプリケーションファイルテーブルを拡張しません。テーブルの変更を手動で更新するには、Now Support ナレッジベース記事「Manual upgrade steps for reparenting table changes in Tokyo (Tokyo でテーブル変更の親を再指定する手動アップグレード手順) [KB1163388]」を参照してください。 | Tokyo | ||||||||||||||||||||
MID Server | 最新のMID Server システム要件については、「MID Server system requirements (MID Server システム要件)」を参照してください。次の Java Runtime Environment (JRE) バージョンがサポートされています。
自動アップグレードを行なうには、すべての MID Server ホストマシンが install.service-now.com のダウンロードサイトにアクセスする必要があります。詳細については、「How the System Manages MID Server Upgrades (システムが MID Server アップグレードを管理する方法)」をご確認ください。 1つの実行可能ファイルパスにつき、 Windows MID Server サービスは1つのみ許可されます。アップグレードした Windows MID Servers に同じインストールフォルダーを指しているサービスが複数ある場合は起動できません。詳しくは『MID Server fails to start (MID Server が起動しない)』を参照してください。 MID Server のアップグレードについて詳しくは次のトピックを参照してください。
| Tokyo | ||||||||||||||||||||
モバイル | ServiceNow クラシックモバイルプアプリから ServiceNow モバイルプラットフォームに移行すると、迅速な開発、オフライン機能、ネイティブモバイルデバイス機能との統合などの機能が活用できます。ServiceNow モバイルプラットフォームへの移行の詳細については、「Migrate from the ServiceNow Classic mobile app to the ServiceNow Mobile Platform (ServiceNow クラシックモバイルアプリから ServiceNow モバイルプラットフォームへの移行)」を参照してください。 ServiceNow Mobile Platform report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、 Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。 | Tokyo | ||||||||||||||||||||
Operational Technology Incident Management v2 | 以前のリリースで Operational Technology Incident Management を使用している場合、以前に OT インシデントユーザー (ot_incident_user) ロールが割り当てられていたユーザーに Operational Technology Incident Management v2 ロールを新たに割り当てる必要があります。詳細については、「Assign new Operational Technology Incident Management roles (新しい Operational Technology Incident Management ロールの割り当て」を参照してください。 | Tokyo | ||||||||||||||||||||
Password Reset | Password Reset report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、 Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。 | Tokyo | ||||||||||||||||||||
Project Portfolio Management | Project Portfolio Management report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、 Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。 Scenario Planning for PPM をバージョン 2.3.0 以降にアップグレードする場合は、統合を機能させるには、従来の Investment Funding アプリケーションを ServiceNow Store にアップグレードする必要があります。従来の Investment Funding から ServiceNow Store アプリケーションへのアップグレード手順の詳細については、「Upgrade Instructions (アップグレード手順)」を参照してください。 | Tokyo | ||||||||||||||||||||
Service Bridge (テクノロジー) | Service Bridge アプリケーションの Tokyo バージョンにアップグレードするには、 Now Support ナレッジベースの記事「Service Bridge- Upgrade steps for San Diego store release to Tokyo store release (Service Bridge - San Diego ストアリリースから Tokyo ストアリリースへのアップグレード手順) [KB1120583]」を参照してください。 | Tokyo | ||||||||||||||||||||
Service Bridge (電気通信) | Tokyo | |||||||||||||||||||||
Service Operations Workspace for ITSM | 次のアプリケーションに互換性のあるアップグレードバージョンが存在することを確認します。
ここで、x は Service Operations Workspace ITSM Applications アプリケーション (sn_sow_itsm_cont) のサブバージョンで、y は Service Operations Workspace ITOM Applications アプリケーション (sn_sow_itom_cont) のサブバージョンです。 | Tokyo | ||||||||||||||||||||
Service Portal |
| Tokyo | ||||||||||||||||||||
Software Asset Management | Software Asset Management Foundation プラグイン (com.snc.sams) のアップグレードについて詳しくは、「Revert Software Asset Management Customizations (Software Asset Management のカスタマイズを元に戻す)」を参照してください。 | Tokyo | ||||||||||||||||||||
Subscription Management | Subscription Management report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、 Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。 | Tokyo | ||||||||||||||||||||
Upgrade Center | Upgrade Center report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、 Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。 | Tokyo | ||||||||||||||||||||
Vendor Management Workspace | Vendor Management Workspace report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、 Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。 | Tokyo | ||||||||||||||||||||
仮想エージェント |
| Tokyo | ||||||||||||||||||||
Visual Task Boards | Visual Task Boards report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、 Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。 | Tokyo | ||||||||||||||||||||
Vulnerability Response integrations |
| Tokyo | ||||||||||||||||||||
Vulnerability Response | Vulnerability Response アプリケーションのデータモデル変更により、アップグレードには以前よりかなり長い時間がかかる場合があります。詳しくは、KB0856498 を参照してください。 新しいバージョンへのアップグレード中は、アップグレード元のデータとバージョンに基づいてアップグレード時間が長くなる場合があります。これは、アップグレード中に追加されたスキーマの変更が原因です。詳しくは、KB0856498 を参照してください。 Vulnerability Response アプリケーションを古いバージョンからバージョン 15.x にアップグレードすると、ベースシステムのデフォルトの修正タスクルールが非アクティブ化されます。詳細については、「Vulnerability Response Workspaces and updates to remediation task and remediation task rules (Vulnerability Response のワークスペースおよび、修正タスクと修正タスクルールの更新)」を参照してください。 Vulnerability Response report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、 Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。
Rome で Vulnerability Response をバージョン 18.0 にアップグレードすると、脆弱性マネージャーのワークスペースはサポートされなくなります。 | Tokyo | ||||||||||||||||||||
Workforce Optimization for ITSM | 予測方法の改善：Demand Forecast では、改善した予測方法を使用してデータを予測します。インジケータースコアを予測するための単純な手法を線形回帰手法にアップグレードしました。以前の単純な手法では、最新のシーズンの最初と最後のスコアのみを使用しましたが、アップグレードした手法では、評価期間中に利用可能なすべてのスコアを使用します。さらに、従来の線形メソッドとドリフトメソッドを単一の線形メソッドに置き換え、95% 予測間隔の計算を改善しました。アップグレードすると、Demand Forecast で使用する予測アルゴリズムが次のように更新されます。
スケジュール計画とシフト計画のテキストインデックス作成の有効化：Workforce Optimization for ITSM バージョン 1.1.1 にアップグレードする場合は、次のテーブルのテキストインデックス作成を有効にする必要があります。
Workforce Optimization for ITSM レポートビュー ACL： report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、 Tokyo リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。 Coaching with Learning：Workforce Optimization for ITSM Tokyo リリース にアップグレードすると、自動的に次の更新が行われます。
ServiceNow ストアから ITSM Shift Planning Host v 5.3.0 アプリケーションにアップグレードした後：
| Tokyo | ||||||||||||||||||||
AI Search | 以前のリリースから Utah にアップグレード後に、タスク [task] テーブルとその子テーブルからレコードにインデックス付けすると、AI Search が新しい自動言語検出機能を適用します。Utah にアップグレードする前にインデックス付けをしたタスクレコードに自動言語検出を適用するには、それらのレコードを手動で再インデックス付けする必要があります。 同様に、以前のリリースから Utah にアップグレードした後で、中国語テキストまたは日本語テキストの領域を持つレコードまたはドキュメントにインデックス付けをすると、AI Search は中国語と日本語の新しいテキスト領域検出機能を自動的に適用します。Utah にアップグレードする前に、インデックス付けしたレコードやドキュメントにテキスト領域検出を適用するには、それらのレコードやドキュメントを手動で再インデックス付けする必要があります。 Utah の新しいインスタンスでは Next Experience 向け AI Search アプリケーションは自動的に有効になります。以前のリリースから Utah にアップグレードした場合、Next Experience 向け AI Search は手動で設定および有効化できます。アプリケーションに関する詳細については、「AI Search for Next Experience (Next Experience 向け AI Search)」を参照してください。 | Utah | ||||||||||||||||||||
エージェントチャットおよび Sidebar | Conversational Interfaces コンソールは Utah リリースに含まれているため、既存のお客様はこれをインストールする必要はありません。ServiceNow Store からアプリとしてインストールした場合は、後続の更新はそこからインストールする必要があります。 | Utah | ||||||||||||||||||||
アセスメントとサーベイ | Utah リリースでは、アセスメントカードとサーベイカードのボタンをすべて削除しました。Automated Test Framework (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 | ||||||||||||||||||||
Configuration Compliance |
| ユタ | ||||||||||||||||||||
Customer Service Management (CSM) | ケースタスクの拡張により、ケースタスクレコードに複数のフィールドが追加されます。Utah リリースにアップグレードすると、顧客はスクリプトを実行してアクティブなケースタスクのこれらのフィールドに入力できます。詳細については、「Cases and case tasks (ケースとケースタスク)」を参照してください。 | Utah | ||||||||||||||||||||
暗号化キー管理 | 暗号化コンテキストは、San Diego リリース以降へのアップグレード時に、Column Level Encryption フィールド暗号化モジュールと対応するモジュールアクセスポリシーに自動的に変換されます。この機能拡張について説明するチュートリアルをダッシュボードから利用できます。 暗号化キー管理 report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、 Utah リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。 | Utah | ||||||||||||||||||||
Hardware Asset Management 7.0.0 | 既存のカスタマイズの構成を変更して、標準レコードページテンプレートと互換性を持たせる必要があります。標準レコードページテンプレートおよび構成変更の詳細については、Now Support ナレッジベースの記事「Work Instruction | How to Migrate existing Record Pages to Standard Record Pages (操作手順｜既存のレコードページの標準レコードページへの移行) [KB1224040]」を参照してください。 | Utah | ||||||||||||||||||||
Health Log Analytics | Health Log Analytic のバージョンが 2022 年 2 月より前の場合は、Now Support または ServiceNow 営業担当者に連絡して、Health Log Analytics アプリケーションコアコンポーネントのアップグレードを要求してください。 | Utah | ||||||||||||||||||||
ID と認証 | ID と認証 report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、 Utah リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。 | Utah | ||||||||||||||||||||
Industrial Process Manager | Manufacturing Process Manager に同梱されている ISA Service Graph Connector を使用し、Industrial Process Manager にアップグレードする場合は、新しい ISA 設備階層モデルエンティティに一意の名前フィールドがあることを確認してください。 | Utah | ||||||||||||||||||||
Instance Data Replication | レプリケーションセットを V2 にアップグレードして Hermes Messaging Service を使用すると Instance Data Replication (IDR) のパフォーマンスと処理効率を向上できます。詳細については、「Upgrading legacy replication set to V2 in Instance Data Replication (Instance Data Replication の V2 への従来のレプリケーションセットのアップグレード」を参照してください。 | Utah | ||||||||||||||||||||
MID Server | 最新のMID Server システム要件については、「MID Server system requirements (MID Server システム要件)」を参照してください。サポートされている Java Runtime Environment (JRE) の最低バージョンは 11.0.9 で推奨バージョンは 11.0.16 です。 独自の JRE をインストールしている場合、アップグレードプロセスは次のアクションを実行して、MID Server がサポートされている JRE を使用するようにします。
自動アップグレードを行なうには、すべての MID Server ホストマシンが install.service-now.com のダウンロードサイトにアクセスする必要があります。詳細については、「How the System Manages MID Server Upgrades (システムが MID Server アップグレードを管理する方法)」をご確認ください。 1つの実行可能ファイルパスにつき、 Windows MID Server サービスは1つのみ許可されます。アップグレードした Windows MID Servers に同じインストールフォルダーを指しているサービスが複数ある場合は起動できません。詳しくは『MID Server fails to start (MID Server が起動しない)』を参照してください。 MID Server のアップグレードについて詳しくは次のトピックを参照してください。
| Utah | ||||||||||||||||||||
Manager Hub | リリースに Washington DC アップグレードする場合は、 の To Do 設定フォーム 従業員センター で To Do マッピングに対して作成された追加条件を Manager Hub、 のマネージャー To Do マッピングモジュールで再度作成する必要があります。 | ユタ | ||||||||||||||||||||
Operational Technology Incident Management v2 | 以前のリリースで Operational Technology Incident Management を使用している場合、以前に OT インシデントユーザー (ot_incident_user) ロールが割り当てられていたユーザーに Operational Technology Incident Management v2 ロールを新たに割り当てる必要があります。詳細については、「Assign new Operational Technology Incident Management roles (新しい Operational Technology Incident Management ロールの割り当て」を参照してください。 | Utah | ||||||||||||||||||||
プラットフォームセキュリティ | データプライバシー機能を使うには Vault エンタイトルメントを取得します。この機能の詳細については、「ServiceNow Vault」を参照してください。 | Utah | ||||||||||||||||||||
Portfolio Planning |
| ユタ | ||||||||||||||||||||
Public Sector Digital Services | アップグレード後、CSM 構成可能ワークスペースの特定の公共部門メニューとメニューアイテムが元の CSM ラベル名に戻ります。公共部門用のこれらのアイテムに再レベル付けするには、顧客およびサービス組織の UX リストカテゴリを更新します。詳細については、「Relabel items for public sector use after upgrade (アップグレード後に公共部門用のアイテムのラベルを変更する)」を参照してください。 | Utah | ||||||||||||||||||||
Robotic Process Automation (RPA) Hub | 現在インストール済みの Microsoft Software Installers (MSI) (RPA Desktop Design Studio、Attended Robot、 Unattended Robot) は、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 | 次のアプリケーションに互換性のあるアップグレードバージョンが存在することを確認します。
ここで、x は Service Operations Workspace ITSM Applications アプリケーション (sn_sow_itsm_cont) のサブバージョンで、y は Service Operations Workspace ITOM Applications アプリケーション (sn_sow_itom_cont) のサブバージョンです。 | ユタ | ||||||||||||||||||||
Service Portal | アップグレード後に、テーブル入力パラメーターを受け入れる公開ウィジェットのデータにゲストユーザーがアクセスできるテーブルを指定する必要があります。デフォルトでは、テーブル入力パラメーターを受け入れるパブリックウィジェットは、ゲストユーザーのどのテーブルからもデータにアクセスして返すことができません。アップグレード前に またはglide.service_portal.widget.allow_listシステムプロパティを追加glide.service_portal.widget.table_allow_listした場合、これらのプロパティの値は、Utah パッチ 10 リリース以降にアップグレードした後にウィジェットの公開テーブル許可リストに移行されます。詳細については、「 ウィジェット セキュリティの構成」をご参照ください。 | ユタ | ||||||||||||||||||||
Service Portfolio Management | 可用性の結果の表示は Tokyo リリースで導入されましたが後続のリリースにも適用されます。アップグレードすると、データ負荷が高いと判断されたお客様の場合、システムが長時間実行型のバックグラウンドジョブを開始し、長い時間継続する場合があります。詳しくは「KB1123644」を参照してください。 | Utah | ||||||||||||||||||||
Software Asset Management | Software Asset Management Foundation プラグイン (com.snc.sams) のアップグレードについて詳しくは、「Revert Software Asset Management Customizations (Software Asset Management のカスタマイズを元に戻す)」を参照してください。 Utah にアップグレードすると、ソフトウェアアシュアランスの対象で汎用バージョンのソフトウェアモデルに関連付けられている既存の無期限ライセンスエンタイトルメントが変更されます。Software Asset Management は 、これらのエンタイトルメントをバージョン固有のソフトウェアモデルに自動的に変換します。これらの変更は、Microsoft のライセンス条項に準拠し、Microsoft 製品のすべてのバージョンにソフトウェア アシュアランス特典を適用する潜在的なリスクを軽減するために行われます。詳細については、「 ソフトウェア ライセンスのメンテナンス」を参照してください。 | ユタ | ||||||||||||||||||||
Strategic Planning |
| ユタ | ||||||||||||||||||||
サプライヤーライフサイクルオペレーション | Utah リリースで、既存のすべてのテーブルの名前が変更されました。名前の変更の一環として、既存のテーブルの新しい名前に含まれる「supplier」という単語がすべて「slm」に変更されました。たとえば、サプライヤーケース [sn_supplier_case] はサプライヤーケース (sn_slm_case) に、サプライヤータスク [sn_supplier_task] はサプライヤータスク (sn_slm_task) に変更されました。Tokyo リリースから Utah リリースにアップグレードする場合は、修正スクリプトを実行して既存のテーブルを Supplier Common Architectureに移行してください。詳細については、「 修正スクリプトによる既存テーブルの Supplier Common Architecture への移行 (Run fix script to migrate existing tables to Supplier Common Architecture)」を参照してください。 | Utah | ||||||||||||||||||||
Upgrade Center | Upgrade Center report_view アクセス制御リスト (ACL)は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、Utah リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。 | Utah | ||||||||||||||||||||
Vulnerability Response integrations |
| Utah | ||||||||||||||||||||
Vulnerability Response | Vulnerability Response アプリケーションのデータモデル変更により、アップグレードには以前よりかなり長い時間がかかる場合があります。詳しくは、KB0856498 を参照してください。 新しいバージョンへのアップグレード中は、アップグレード元のデータとバージョンに基づいてアップグレード時間が長くなる場合があります。この問題は、アップグレード中に追加されたスキーマの変更が原因です。詳しくは、KB0856498 を参照してください。 Rome で Vulnerability Response をバージョン 18.0 にアップグレードすると、脆弱性マネージャーのワークスペースはサポートされなくなります。 | Utah | ||||||||||||||||||||
AI Search |
| Vancouver | ||||||||||||||||||||
アセスメントとサーベイ | Utah より前のバージョンから Vancouver にアップグレードする場合は、Automated Test Framework (ATF) テストを更新します。Utah リリースでは、アセスメントカードとサーベイカードのボタンをすべて削除しました。ATF テストを正常に実行するには、このステップを含むすべてのテストについて、「サーベイの実施ボタンをクリックする」ステップを「サーベイカードをクリックする」のステップに置き換える必要があります。 | Vancouver | ||||||||||||||||||||
Automated Test Framework | Now Platform®で提供されているクイックスタートテストをコピーしカスタマイズして、構成変更後もインスタンスが動作することを検証します。たとえば、アップグレードを適用するか、アプリケーションを開発する場合です。 カスタマイズを行っていないベースシステム上で、アプリケーションまたは機能プラグインが提供するデフォルトのデモデータを使用してテストを実行した場合にのみ、テストで合格の結果を生成できます。インスタンス固有のデータにクイックスタートテストを適用するには、クイックスタートテストをコピーしてカスタムデータを追加します。詳しくは、「Available quick start tests by application or feature (アプリケーションおよび機能別に利用可能なクイックスタートテスト)」を参照してください。 | Vancouver | ||||||||||||||||||||
クラウドコスト管理 | クラウドコスト管理を Vancouver にアップグレードする手順については、「クラウドインサイトのアップグレード」を参照してください。 | Vancouver | ||||||||||||||||||||
Configuration Management Database (CMDB) | アップグレード中に、調整定義マッピング [cmdb_reconciliation_definition_mapping] テーブルを再ペアレンティングする修正スクリプトが実行されます。この修正スクリプトが完了するまでの時間は、アップグレードされたインスタンスの調整ルールの数によって異なり、通常はアップグレードに数分かかります。 調整定義マッピング [cmdb_reconciliation_definition_mapping] テーブルを再ペアレンティングすることは、インスタンス間で調整ルールをエクスポートするときにそのテーブルのデータが更新セットによってキャプチャされるようにするために必要です。アップグレード後、調整ルールへの変更は更新セットによって完全にキャプチャされ、宛先インスタンスに適切に移植されます。 | Vancouver | ||||||||||||||||||||
Document Intelligence | Document Intelligence 3.0 以降には、スコープ対象のアプリケーションから Now Platform プラグインへの移行をサポートする更新されたスキーマが含まれています。アップグレードの詳細については、「 バージョン 2.4 以前から Document Intelligence 3.0 以降にアップグレードする」を参照してください。 | Vancouver | ||||||||||||||||||||
Goal Framework | v4.2.0 以降、[ タイプ ] フィールドが [マイルストーン ] に設定されている既存のターゲットは、定性的ターゲットと見なされます。Goal Framework をアップグレードすると、このような既存のターゲットの場合、測定単位は [はい]/[いいえ] に設定され、[基準] の値は [いいえ] に設定され、[ターゲット] の値は自動的に [はい] に設定されます。また、進捗値が 100 の場合、[実績] の値は [ はい ] に設定され、それ以外の場合は [ いいえ] に設定されます。 | Vancouver | ||||||||||||||||||||
ITOM Visibility |
| Vancouver | ||||||||||||||||||||
ID と認証 | ID と認証 report_view アクセス制御リスト (ACL) は、ダッシュボードなどでレポートを表示できるユーザーを管理するもので、Vancouver リリースではデフォルトで有効になっています。詳細については、「Report_view access control (Report_view のアクセス制御)」を参照してください。 | Vancouver | ||||||||||||||||||||
Industrial Process Manager | Manufacturing Process Manager に同梱されている ISA Service Graph Connector を使用し、Industrial Process Manager にアップグレードする場合は、新しい ISA 設備階層モデルエンティティに一意の名前フィールドがあることを確認してください。 | Vancouver | ||||||||||||||||||||
Instance Data Replication | レプリケーションセットを V2 にアップグレードして Hermes Messaging Service を使用すると Instance Data Replication (IDR) のパフォーマンスと処理効率を向上しす。詳細については、「Upgrading legacy replication set to V2 in Instance Data Replication (Instance Data Replication の V2 への従来のレプリケーションセットのアップグレード)」を参照してください。 インスタンスのレプリケーションペイロードエラー [idr_replication_payload_error] テーブルに 1,000 万件を超えるレコードがある場合は、KB1364728 に従ってテーブルローテーションを設定します。テーブルローテーションを使用してレプリケーションペイロードエラー [idr_replication_payload_error] テーブルからレコードを削除すると、このテーブルには IDR によってログに記録されたレプリケーションエラーのみが含まれ、レプリケートされたデータは含まれないため、安全です。 | Vancouver | ||||||||||||||||||||
MID Server | 最新の MID Server システム要件については、「MID Server system requirements (MID Server システム要件)」を参照してください。サポートされている JRE の最小バージョンは 11.0.9 で、推奨バージョンは 11.0.16.1 です。 独自の JRE をインストールしている場合、アップグレードプロセスは次のアクションを実行して、MID Server がサポートされている JRE を使用するようにします。
自動アップグレードを行なうには、すべての MID Server ホストマシンが install.service-now.com のダウンロードサイトにアクセスする必要があります。詳細については、「How the System Manages MID Server Upgrades (システムが MID Server アップグレードを管理する方法)」をご確認ください。 1つの実行可能ファイルパスにつき、 Windows MID Server サービスは1つのみ許可されます。アップグレードした Windows MID Servers に同じインストールフォルダーを指しているサービスが複数ある場合は起動できません。詳しくは『MID Server fails to start (MID Server が起動しない)』を参照してください。 MID Server のアップグレードについて詳しくは次のトピックを参照してください。
| Vancouver | ||||||||||||||||||||
Order Management | 2023 年 11 月のリリース以降、Order Management アプリケーションは、電気通信、メディア、およびテクノロジー向け Order Management アプリケーションで提供される注文履行機能を含む、製品およびサービスの注文の完全なライフサイクルをサポートします。Telecommunications Service Management サブスクリプションをお持ちの場合は、 ServiceNow Store から Order Management for Telecom, Media and Tech アプリケーションをインストールします。このアプリケーションは、 Order Management アプリケーション、電気通信デモデータ、および TM Forum API REST 仕様の次の ServiceNow オープン API 実装をインストールします。
Order Management for Customer Service Management アプリケーションに精通している場合は、 Order Management アプリケーションをインストールした後、オプションでそのインターフェイスを使用できます。詳細については、「 Order Management for Customer Service Management KB1554296 のユーザー インターフェイスを有効にする」を参照してください。インターフェイスの変更については、「 Order Management for Customer Service Management アプリケーションKB1560237の変更」を参照してください。 アップグレード中、注文タスク [sn_ind_tmt_orm_order_task] テーブルは、Customer Service Management アプリケーションで使用される予定タスク [planned_tasks] テーブルから拡張されます。注文タスクテーブルも変更されました。注文タスクテーブルの変更に関する詳細については、「OMT Reparenting data model changes (OMT 再親化データモデルの変更) KB1496935」を参照してください。 Vancouver リリースにアップグレードし、バージョン 5.2.0 以外のバージョンの Order Management for Telecommunications, Media, and Technology for Telecommunications, Media, and Technology アプリケーションを使用している場合、製品在庫と製品モデル特性を設定するための修正は利用できません。これらの変更を取得するには、現在の Vancouver パッチにアップグレードします。 | Vancouver | ||||||||||||||||||||
Platform Analytics ワークスペース | Platform Analytics Workspace (3.0) の Vancouver バージョンには、以前は ServiceNow® Store でのみ利用可能だったバージョン 2.1.x の更新が含まれています。 | Vancouver | ||||||||||||||||||||
ポートフォリオ計画立案 |
| Vancouver | ||||||||||||||||||||
Process Automation Designer | Vancouver にアップグレードした後、ServiceNow Store で アプリケーションを更新します。 | Vancouver | ||||||||||||||||||||
Public Sector Digital Services | Public Sector Digital Services v8.0 にアップグレードする前に、[提供されるサービス] テーブルのデータ、[受けたサービス] テーブルのデータ、および [提供されるサービス] テーブルから [サービス定義] テーブルへの変換によって影響を受けるその他すべてのデータ (Performance Analytics ダッシュボードデータ、構成員またはビジネスレポートデータなど) のカスタムサービス定義を作成する必要があります。以前のリリースで作成されたカスタムサービス提供データと受けたサービスデータは、新しいリリースに自動的に移行されず、アップグレード後は、データが従来のエンティティからサービス定義テーブルに移行されるまで、アプリケーション内でアクセスできなくなります。詳細については、「 提供されるサービスと受けたサービスの移行ガイダンス 」および 「Public Sector Digital Services での Playbook のサービス定義の構成」を参照してください。 アップグレード後、CSM 構成可能ワークスペースの特定の公共部門メニューとメニューアイテムが元の CSM ラベル名に戻ります。公共部門用のこれらのアイテムに再レベル付けするには、顧客およびサービス組織の UX リストカテゴリを更新します。詳細については、「Relabel items for public sector use after upgrade (アップグレード後に公共部門用のアイテムのラベルを変更する)」を参照してください。 | Vancouver | ||||||||||||||||||||
Robotic Process Automation (RPA) Hub | 現在インストール済みの Microsoft Software Installers (MSI) (RPA Desktop Design Studio、Attended Robot、Unattended Robot、および Unattended Robot 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 にアップグレードすると、ボットプロセス定義は新しい構造、つまりボットプロセス構成に変更されます。ただし、ボットプロセス構成がボットプロセスを完全に置き換えるわけではありません。ほとんどのフィールドがボットプロセスからボットプロセス構成に移動されます。 システムプロパティ値を更新せずに Utah バージョンにアップグレードすると、テーブルは [アプリケーションファイル] テーブルを拡張しません。テーブルの変更を手動で更新するには、Now Support ナレッジベースの記事「Restructuring RPA Hub tables to sys_metadata in Utah (Utah の sys_metadata への RPA Hub テーブルの再構築)」を参照してください。 | Vancouver | ||||||||||||||||||||
Security Incident Response | Vancouver | |||||||||||||||||||||
Service Bridge | 新しい Service Bridge アプリケーションのアップグレードと使用の詳細については、「Service Bridge からの移行 (レガシ)」を参照してください。 | Vancouver | ||||||||||||||||||||
Service Operations Workspace for ITSM | 次のアプリケーションに互換性のあるアップグレードバージョンが存在することを確認します。
ここで、x は Service Operations Workspace ITSM Applications アプリケーション (sn_sow_itsm_cont) のサブバージョンで、y は Service Operations Workspace ITOM Applications アプリケーション (sn_sow_itom_cont) のサブバージョンです。 アップグレードされたインスタンスに次のいずれかのカスタマイズが含まれている場合は、標準レコードページの変更を移行する必要があります。詳細については、「 Service Operations Workspace の標準レコードページを構成する」を参照してください。
3.0 のアップグレード後は、 推奨フレームワーク 機能は使用できなくなり、代わりに、 Recommended Actions for ITSM 機能の標準バージョンのみが使用できます。 | Vancouver | ||||||||||||||||||||
Service Portfolio Management | 可用性の結果の表示は Tokyo リリースで導入されましたが後続のリリースにも適用されます。アップグレードすると、データ負荷が高いと判断されたお客様の場合、システムが長時間実行型のバックグラウンドジョブを開始し、長い時間継続する場合があります。詳細については、「KB1123644」を参照してください。 | Vancouver | ||||||||||||||||||||
Skills Management | [スキルを管理] ページの 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 | ||||||||||||||||||||
Software Asset Management | Software Asset Management Foundation プラグイン (com.snc.sams) のアップグレードについて詳しくは、「Revert Software Asset Management Customizations (Software Asset Management のカスタマイズを元に戻す)」を参照してください。 Vancouver にアップグレードすると、検出マップ (DMAP) 定義の [バージョン] フィールドと [エディション] フィールドで新しい is_empty 値がサポートされます。既存の Microsoft SQL Server コンポーネント DMAP 定義の [エディション] フィールドが以前に is_anything に設定されていた場合、コンテンツの更新後に新しい is_empty 値で自動的に更新されます。 | Vancouver | ||||||||||||||||||||
戦略的計画 |
| Vancouver | ||||||||||||||||||||
Telecommunications Service Operations Management | Integration Hub スターターパッケージは、外部トリガーとともに、 Vancouver パッチ 1 のスターターパッケージのコンポーネントとして含まれています。Telecommunications API 通知機能を取得するには、ファミリーリリースの Vancouver Patch 1 を使用する必要があります。 | Vancouver | ||||||||||||||||||||
サードパーティリスク管理 | Vancouver | |||||||||||||||||||||
Vulnerability Response integrations |
| Vancouver | ||||||||||||||||||||
Vulnerability Response | Vulnerability Response アプリケーションのデータモデル変更により、アップグレードには以前よりかなり長い時間がかかる場合があります。詳しくは、KB0856498 を参照してください。 新しいバージョンへのアップグレード中は、アップグレード元のデータとバージョンに基づいてアップグレード時間が長くなる場合があります。この問題は、アップグレード中に追加された追加のスキーマ変更が原因です。詳しくは、KB0856498 を参照してください。 Vulnerability Response アプリケーションのバージョン 20.0 および Vulnerability Emergency Response アプリケーションのバージョン 2.03 以降、脆弱性アナリストワークスペースの名前は Vulnerability Assessment Workspace に変更されています。脆弱性アナリストワークスペースへの参照はすべて脆弱性アセスメントワークスペースになりました。 | Vancouver | ||||||||||||||||||||
AI Search | ワシントン DC にアップグレードすると、新しい [AI Search Genius 結果の構成] フォームフィールドを使用するように、AI Search によって既存の Genius 結果構成が自動的に更新されます。この更新手順では、次の変更が行われます。
インスタンスをワシントン DC にアップグレードした後も、AI Search は、検索クエリに複数の用語 ( glide.ais.query.search_operator ) システムプロパティが含まれている場合に使用するブール検索演算子に以前に設定した値を保持します。複数用語検索で新しい拡張クエリモードの利点を得るには、このシステムプロパティの値を AND then OR 2+ key termsに設定します。AI Search システムプロパティの詳細については、「AI Search システムプロパティ」を参照してください。 ワシントン DC 以降、ユーザー [sys_user] テーブルのデフォルトでは、インデックス付きレコードはsys_updated_on日付でソートされるのではなく、sys_created_on日付でソートされます。この変更では、 AI Search のユーザーテーブルのインデックス付きソースのインデックス再作成が必要で、時間がかかる場合があります。以前のファミリリリースから Washington DC にアップグレードする場合、 AI Search はユーザーテーブルのインデックス付きソースを自動的にインデックス再作成しません。ユーザーレコードの最新の構成を検索できるようにする必要がある場合は、ユーザーテーブルのインデックス付きソース のインデックスを手動で再作成 できますが、これには時間がかかる場合があります。そうしないと、 AI Search は、すべてのレコードのインデックスが再作成されるまで、個々のユーザーテーブルレコードが更新されたときにインデックスを再作成します。 | Washington DC | ||||||||||||||||||||
Automated Test Framework | Now Platform®で提供されているクイックスタートテストをコピーしカスタマイズして、構成変更後もインスタンスが動作することを検証します。たとえば、アップグレードを適用するか、アプリケーションを開発する場合です。 カスタマイズを行っていないベースシステム上で、アプリケーションまたは機能プラグインが提供するデフォルトのデモデータを使用してテストを実行した場合にのみ、テストで合格の結果を生成できます。インスタンス固有のデータにクイックスタートテストを適用するには、クイックスタートテストをコピーしてカスタムデータを追加します。詳しくは、「Available quick start tests by application or feature (アプリケーションおよび機能別に利用可能なクイックスタートテスト)」を参照してください。 | Washington DC | ||||||||||||||||||||
Business Continuity Management | ワシントンDCリリースにアップグレードする場合は、既存のビジネスインパクト分析、事業継続性計画、およびイベントについて、次の重要な情報に注意する必要があります。
| Washington DC | ||||||||||||||||||||
Configuration Management Database (CMDB) |
| Washington DC | ||||||||||||||||||||
Core Now Platform | 以前は、トランザクションがキャンセルされた場合に特定の監査可能な操作が記録されませんでした。監査レコードが見つからないこの動作は、レコードの変更と監査の作成前にプラットフォームがレコードの変更の間に一部の操作を実行し、キャンセルされるためです。しかし、現在では、レコードが変更された直後に監査が作成されるため、監査が記録される前にキャンセルされたトランザクションによって操作が中止される可能性が低くなります。この更新を容易にするために、監査はトランザクションと同じスレッドに記録されるようになりました。以前の監査はバックグラウンドスレッドで作成されていました。 この変更により、 | Washington DC | ||||||||||||||||||||
暗号化キー管理 | インスタンスを Washington DC にアップグレードしても、 MID Server をアップグレードしない場合、シークレット管理認証は失敗します。MID Server をワシントン DC にアップグレードすることで、認証エラーを回避します。アップグレードできない場合は、認証の失敗を避けるために、 MID Server が ワシントン DC にアップグレードされるまでは認証をオフにする必要があります。 MID Server のアップグレードの詳細については、「 MID Server のアップグレード」を参照してください。 | Washington DC | ||||||||||||||||||||
Enterprise Asset Management | ワシントン DC にアップグレードすると、エンタープライズ資産 [sn_ent_asset] テーブルで [model_component] フィールドを使用できなくなります。代わりに、資産 [alm_asset] テーブルで新しいmodel_component_idフィールドを使用できます。[ENT - 新しいモデルに移行] コンポーネントスクリプトは、既存のmodel_componentフィールドデータをmodel_component_idフィールドに移動します。 資産の総所有コスト (TCO) について、次のアップグレードシナリオに注意してください。
| Washington DC | ||||||||||||||||||||
Financial Services Operations Core | ワシントン DC へのアップグレード中に、Financial Services Operations Core プラグインは次のテーブルを再ペアレンティングします。
注: アップグレードされたインスタンスに多数のレコードがある場合は、アップグレードが完了するまでに時間がかかることがあります。
| Washington DC | ||||||||||||||||||||
Hardware Asset Management 10.0.0 | ワシントン DC にアップグレードした後は、資産の総所有コスト (TCO) について、次のアップグレードシナリオに留意してください。
| Washington DC | ||||||||||||||||||||
Healthcare and Life Sciences Service Management Core | ワシントン DC へのアップグレード中に、ヘルスケア販売済み製品 [sn_hcls_sold_product] 親テーブルが、次のテーブルのインストールベースアイテム [sn_install_base_item] に変更されます。
また、次のテーブルは親テーブルが削除されており、スタンドアロンテーブルになっています。
既存のデータは、既存の機能が影響を受けないように、次の方法で移行されます。
注: アップグレードされたインスタンスに多数のレコードがある場合は、アップグレードが完了するまでに時間がかかることがあります。 | Washington DC | ||||||||||||||||||||
Instance Data Replication | レプリケーションセットを V2 にアップグレードして Hermes Messaging Service を使用すると Instance Data Replication (IDR) のパフォーマンスと処理効率を向上しす。詳細については、「Upgrading legacy replication set to V2 in Instance Data Replication (Instance Data Replication の V2 への従来のレプリケーションセットのアップグレード)」を参照してください。 アップグレード後に、レプリケーションペイロードエラー [idr_replication_payload_error] テーブルのログローテーションが自動的に有効になります。デフォルトでは、ログローテーションスケジュールは 7 つのシャードで構成され、シャードごとに 5 日間あります。アップグレード前に作成されたこのテーブルのログエントリはすべて自動的に切り捨てられます。 | Washington DC | ||||||||||||||||||||
MID Server | 最新の MID Server システム要件については、「MID Server system requirements (MID Server システム要件)」を参照してください。サポートされている JRE の最小バージョンは 11.0.9 で、推奨バージョンは 11.0.16.1 です。 独自の JRE をインストールしている場合、アップグレードプロセスは次のアクションを実行して、MID Server がサポートされている JRE を使用するようにします。
自動アップグレードを行なうには、すべての MID Server ホストマシンが install.service-now.com のダウンロードサイトにアクセスする必要があります。詳細については、「How the System Manages MID Server Upgrades (システムが MID Server アップグレードを管理する方法)」をご確認ください。 1つの実行可能ファイルパスにつき、 Windows MID Server サービスは1つのみ許可されます。アップグレードされた Windows MID Server に同じインストールフォルダーを指しているサービスが複数ある場合は起動できません。詳しくは『MID Server fails to start (MID Server が起動しない)』を参照してください。 MID Server のアップグレードについて詳しくは次のトピックを参照してください。
| Washington DC | ||||||||||||||||||||
Order Management | この ワシントン DC リリースで導入された新機能は、 Order Management の以前のリリースではサポートされていません。 | Washington DC | ||||||||||||||||||||
Performance Analytics | 従来の PA スコア [pa_scores] テーブルは廃止されます。PA スコアテーブルにキャプチャされたインジケータースコアがまだある場合、そのようなスコアの数が 4,300 万未満の場合、これらのスコアはアップグレード時にpa_scores_l1テーブルとpa_scores_l2テーブルに自動的に移行されます。アップグレードに追加される予定時間は約 2 時間です。詳細については、パフォーマンス分析スコアのKB1294371または移行を参照してください。 | Washington DC | ||||||||||||||||||||
プラットフォーム分析エクスペリエンス | プラットフォーム分析 エクスペリエンス機能は、以前は Platform Analytics Workspace にありました。この機能はコア Now Platform の一部となり、 Next Experience 統一ナビゲーションからアクセスできるようになりました。コア UI で作成されたダッシュボード、レポート、および Performance Analytics ウィジェットをこの機能に移行できます。 | Washington DC | ||||||||||||||||||||
Playbook | ワシントン DC にアップグレードした後、ServiceNow Store の Playbook および Workflow Studio アプリケーションを更新します。 | Washington DC | ||||||||||||||||||||
ポートフォリオ計画立案 | v8.0.0 以降、 Strategic Portfolio Management (SPM) Pro ライセンス機能には Strategic Planning Workspace でのみアクセスできます。SPM Pro ライセンスを所有していても、Portfolio Planning Workspace で SPM Pro ライセンスの機能 (目標、製品フィードバック、ハイブリッドポートフォリオ計画、追加レンズなど) を使用している場合、そのような機能にアクセスするには Strategic Planning をインストールする必要があります。Strategic Planning Workspace でのみアクセスできる機能の詳細については、「Portfolio Planning と Strategic Planning の比較」を参照してください。 | Washington DC | ||||||||||||||||||||
Predictive Intelligence | ワシントン DC にアップグレードする場合、新しい回帰ソリューションを作成することはできません。既存のソリューションがある場合、それらは引き続きサポートされ、トレーニングと変更はできますが、新しいソリューションを作成することはできません。 類似性ソリューションとクラスタリングソリューションへの変更は、 ワシントン DC にあるすべてのインスタンスに適用されます。 | Washington DC | ||||||||||||||||||||
Proactive Service Experience Workflows | トラブルチケット通知を受信したくないお客様は、インシデントテーブルとケーステーブルに関連するビジネスルールを無効にすることができます。トラブルチケット通知のビジネスルールを無効にする方法の詳細については、「 トラブルチケット通知の非アクティブ化」を参照してください。 | Washington DC | ||||||||||||||||||||
Public Sector Digital Services | アップグレード後、CSM 構成可能ワークスペースの特定の公共部門メニューとメニューアイテムが元の CSM ラベル名に戻ります。公共部門用のこれらのアイテムに再レベル付けするには、顧客およびサービス組織の UX リストカテゴリを更新します。再ラベル付けの詳細については、 をクリックし、 . | ワシントン DC | ||||||||||||||||||||
Robotic Process Automation (RPA) Hub | RPA アプリケーションをダウンロードして、次の Microsoft ソフトウェアインストーラー (MSI) のいずれかをアップグレードしてください。
次のアップグレード手順は、 San Diego または Tokyo から Washington DC にアップグレードする場合にのみ適用されます。 アプリケーションファイルテーブルのレコード数に基づいて、 RPA Hub アプリケーションを Tokyo 以前から ワシントン DC にアップグレードする際に遅延が発生する可能性があります。 RPA Hub を Washington DC にアップグレードする前に、システムプロパティの値を glide.rollback.blacklist.TableParentChange.changefalse に設定する必要があります。このプロパティがシステムプロパティ [sys_properties] テーブルに存在しない場合は、プロパティを追加し、その値を false に設定します。プロパティの追加方法の詳細については、「 システム プロパティを追加する」を参照してください。 ワシントン DC にアップグレードすると、ボットプロセス定義が新しい構造 (ボットプロセス構成) に変更されます。 ボットプロセス構成がボットプロセスを完全に置き換えるわけではありませんが、ほとんどのフィールドはボットプロセスからボットプロセス構成に移動されます。システムプロパティ値を更新せずに Utah バージョンにアップグレードすると、テーブルは [アプリケーションファイル] テーブルを拡張しません。テーブルの変更を手動で更新するには、Now Support ナレッジベースの記事「Restructuring RPA Hub tables to sys_metadata in Utah (Utah で RPA Hub テーブルの再構築)」を参照してください。 | Washington DC | ||||||||||||||||||||
Service Operations Workspace for IT Service Management | 次のアプリケーションに互換性のあるアップグレードバージョンが存在することを確認します。
この表で、x は Service Operations Workspace ITSM Applications アプリケーション (sn_sow_itsm_cont) のサブバージョン、y は Service Operations Workspace ITOM Applications アプリケーション (sn_sow_itom_cont) のサブバージョンです。 3.0 のアップグレード後、 推奨フレームワーク 機能は使用できなくなります。代わりに、 Recommended Actions for ITSM 機能の標準バージョンのみを使用できます。 | Washington DC | ||||||||||||||||||||
Service Portal | アップグレード後に、テーブル入力パラメーターを受け入れる公開ウィジェットのデータにゲストユーザーがアクセスできるテーブルを指定する必要があります。デフォルトでは、ワシントン DC リリースでは、テーブル入力パラメーターを受け入れる公開ウィジェットは、ゲストユーザーのどのテーブルからもデータにアクセスして返すことができません。アップグレード前に またはglide.service_portal.widget.allow_listシステムプロパティを追加glide.service_portal.widget.table_allow_listした場合、これらのプロパティの値は、アップグレード後にウィジェットの公開テーブル許可リストに移行されます。詳細については、「 ウィジェット セキュリティの構成」をご参照ください。 ユーザーが以前に、プラットフォームの他の部分とは異なるポータルの User Experience Analytics のユーザー同意設定を選択した場合、プラットフォーム用に選択された設定は、 ワシントン DC リリースのポータルにも使用されます。たとえば、ユーザーがポータルの追跡をオプトアウトし、 Vancouver リリースではプラットフォームの残りの部分の追跡をオプトインした場合、ポータルのユーザーエクスペリエンス分析はワシントン DC リリースで追跡されます。ユーザーは、ポータルのユーザープロファイルページからいつでも選択内容を更新できます。 | Washington DC | ||||||||||||||||||||
Software Asset Management | ワシントン DC にアップグレードした後、ServiceNow インスタンスとの Adobe および Microsoft 365 の統合に関連するすべてのカスタマイズをやり直す必要があります。これらの統合の機能は Software Asset Management – SaaS License Management ストアアプリケーションに移動されるためです。
| Washington DC | ||||||||||||||||||||
戦略的計画 | v4.0.2 以降、 Strategic Portfolio Management (SPM) Pro ライセンス機能には、 Strategic Planning Workspace でのみアクセスできます。SPM Pro ライセンスを所有していても、Portfolio Planning Workspace で SPM Pro ライセンスの機能 (目標、製品フィードバック、ハイブリッドポートフォリオ計画、追加レンズなど) を使用している場合、そのような機能にアクセスするには Strategic Planning をインストールする必要があります。Strategic Planning Workspace でのみアクセスできる機能の詳細については、「Portfolio Planning と Strategic Planning の比較」を参照してください。 | Washington DC | ||||||||||||||||||||
サプライヤーライフサイクルオペレーション | Vancouver リリースから Washington DC リリースにアップグレードすると、[All] ナビゲーションタブには Source-to-Pay ワークスペースのみが表示されます。Source-to-Pay ワークスペースを引き続き使用することを選択した場合は、何もする必要はありません。 ただし、[ワークスペース] タブには、調達から支払いまでのワークスペースとサプライヤーマネージャーワークスペースの両方が表示されます。デフォルトの調達から支払ワークスペースの代わりにサプライヤーマネージャーワークスペースを使用する場合は、ワシントンDCリリースにアップグレードした後にfixscript_migrate_workspace_to_smw.xml修正スクリプトを実行してください。fixscript_migrate_workspace_to_smw.xmlファイルは ServiceNow Store からダウンロードできます。修正スクリプトの実行方法の詳細については、「 修正スクリプトの実行」を参照してください。 調達から支払ワークスペースの使用に戻す場合は、fixscript_migrate_workspace_to_s2p.xml修正スクリプトを実行します。fixscript_migrate_workspace_to_smw.xmlファイルは ServiceNow Store からダウンロードできます。修正スクリプトの実行方法の詳細については、「 修正スクリプトの実行」を参照してください。 | Washington DC | ||||||||||||||||||||
UI ビルダー | ワシントン DC にアップグレードした後、ServiceNow Store から UI Builder アプリケーションを更新します。 | Washington DC | ||||||||||||||||||||
Vulnerability Response integrations |
| Washington DC | ||||||||||||||||||||