Sandbox へのテスト移行の実行

学習の目的

この単元を完了すると、次のことができるようになります。

複数の記事タイプを使用する組織を移行する。
記事の項目をまとめて対応付けることで統合する。
移行の概要を確認する。
移行を検証して受け入れる。

移行開始

Maria は、計画と事前作業を終えました。移行前チェックリストを完了し、必要な変更を行いました。Lightning Knowledge の制限事項を再確認し、グループが影響を受けないことを確かめました。自分のリストを作成し、それらをしっかり確認しました。ここで彼女は、移行プロセスに関する短い動画を見ます。

このモジュールでは、受講者が Salesforce システム管理者であり、Lightning Knowledge に移行する適切な権限を有していると想定しています。ただし、Lightning Knowledge の管理者でなくても問題ありません。このまま読み進み、本番組織で管理者がこれらの手順をどのように実行するのかを学習しましょう。Trailhead Playground で次の手順を実行しないでください。Trailhead Playground では Lightning Knowledge への移行を実行できません。

Lightning Knowledge 移行ツールの起動

移行の動作を確認したので、次は Lightning Knowledge 移行ツールを起動します。このツールに従って、移行プロセスの各部分を順に実行できます。

移行元の組織で、Lightning Experience に切り替えます。Maria の場合は、それは Ursa Major のサービス組織です。
[設定] から、[クイック検索] ボックスに「データ」と入力し、[Lightning Knowledge 移行ツール] をクリックします。
Trailhead Playground で作業している場合、Lightning Knowledge 移行ツールは使用できません。それらの組織では、すでに Lightning Knowledge が実行されています。
ドキュメントを読んだことと、サービスの利用規約に同意することを確認するチェックボックスをオンにします。
[開始] をクリックします。
移行する記事タイプとカスタム項目のリストを確認します。Maria は、2 つの記事タイプと 10 個のカスタム項目を使用します。
[次へ] をクリックします。

次のステップでは、記事の項目をまとめて対応付けることで統合します。

記事項目の対応付け

移行中に項目をどのように統合するかを示すために Maria が作成したスプレッドシートを覚えていますか? そこには、統合する項目、項目名、項目を度の値に対応付けるかがリストされています。統合する項目のデータ型と機能は同じである必要があります。現在、Maria は 8 つのリッチテキスト項目を 4 つに統合しようとしています。目的は、詳細の項目、原因の項目、解決策の項目、コメントの項目を 1 つずつにすることです。

スプレッドシート。「統合する項目」列に Details (詳細)、Cause (原因)、Resolution (解決策)、Comments (コメント) が含まれています。「項目名」列には、FAQ_Details、Procedure_Details、FAQ_Cause、Procedure_Cause、FAQ_Resolution、Procedure_Resolution、FAQ_Comments、Procedure_Comments が含まれています。「項目の対応付け」列には、FAQ_Details、FAQ_Cause、FAQ_Resolution、FAQ_Comments が含まれています。

このステップでは、その対応付けを設定します。

Lightning Knowledge 移行ツールで、項目を確認します。各新規項目に「記事タイプ_項目名」の形式のプレースホルダー項目があります。[FAQ] タブには、[FAQ_Details]、[FAQ_Cause]、[FAQ_Resolution]、[FAQ_Comments] のプレースホルダー項目が表示されています。
適切なタブをクリックして、対応付ける項目を含む記事タイプにアクセスします。Maria は、[Procedure (手順)] をクリックして項目を見つけます。
統合する項目を対応付けます。Maria は、[Procedure (手順)] タブの [Details (詳細)] 項目の [新規項目] 列で [FAQ_Details] を選択します。この選択によって、[Procedure_Details] 項目が [FAQ_Details] 項目に対応付けられます。[Cause (原因)]、[Resolution (解決策)]、[Comments (コメント)] についてもこのプロセスを繰り返します。
[次へ] をクリックします。

デフォルトのファイル表示の設定

次に Maria は、移行したファイルのデフォルトの表示を選択します。移行時に、Classic のファイルは Classic のファイル項目から Lightning Knowledge のファイルオブジェクトと関連リストに移動されます。移行後のファイルの権限を決定する必要があります。2 つの選択肢があります。

内部ユーザーのみ。移行後は、内部ユーザーのみにファイルが表示されます。Experience Cloud ユーザーに対して権限が付与されていた場合、そのユーザーにはファイルが表示されなくなります。
以前に権限を持っていたすべてのユーザー。Classic でファイルが表示されていたすべてのユーザーに移行後もファイルが表示されます。

Maria は、既存のファイルの大半に対応する設定をデフォルトとして選択します。標準以外の権限のファイルのリストを持っているので、それらのファイルは移行後に権限を変更します。

Lightning Knowledge 移行ツールで、ファイルの表示を選択します。Maria は、[すべてのユーザー] を選択します。
[次へ] をクリックします。
最後の画面には 2 つの注意事項が表示されます。移行中に知識ベースを変更してはいけないことと、移行後は Lightning Knowledge を無効にできないことです。Maria は十分に下調べを行っていたので、すでに Classic の [記事アクションの設定] ノードでユーザーの作成権限を無効にしてあります。また、本番組織で実行する前に、まず Sandbox に移行してプロセスをテストしています。開始する準備が整いました。
[Begin (開始)] をクリックします。

正式に移行が進行中になりました。[Lightning Knowledge 移行ツール] ページを再読み込みすると状況を確認できます。また、移行が完了するとメールが送信されます。

移行の有効化

Maria は、次の月曜日の朝早く、大きなカップに入ったコーヒーを持って出勤しました。移行が完了したことを通知するメールを受信してご機嫌です。彼女は、Lightning Knowledge 移行ツールにアクセスし、[データ移行の概要] を表示します。

後でトラブルシューティングに必要になった場合に備えて、スクリーンショットを取得します。必要にならないとは思いますが、彼女は慎重な性格です (ToDo リストを覚えていますか?)。

Lightning Knowledge 移行ツールの [データ移行の概要] に、移行された内容 (記事、記事履歴、バージョンなど) が表示されています。

各行の横にあるアイコンを確認します。問題がある場合は、黄色の警告フラグが表示されます。Maria の場合は、緑のチェックマークのみが表示されました。つまり、次のステップに進む準備ができているということです。
[次へ] をクリックして Lightning Knowledge を有効にします。
[有効化] をクリックして準備ができていることを確認します。

移行ツールによって新しいナレッジオブジェクトと Lightning Knowledge ユーザーインターフェースが有効化されます。既存の記事タイプは無効になります。フィードとスマートリンクは移行されます。フィード投稿の移行中は、記事のフィードコンポーネントは一時的に表示されなくなります。完了すると、フィードコンポーネントが再び表示されます。

移行した組織の検証

Maria には、検証する項目のリストがあります。順序は特に決まっていませんが、移行の結果を受け入れる前にすべての項目を検証する必要があります。まず、記事タイプを参照するすべてのカスタマイズを更新する必要があります。これらの参照を削除して移行後に修正するか、この時点で新しいナレッジオブジェクトを参照するように変更できます。

機能	記事タイプへの参照の更新方法
カスタマイズ	カスタムアプリケーションを調べて、古い記事タイプを参照しているものがないことを確認します。Apex コード、エクスペリエンスビルダーサイト、サイト、データフローを確認します。プロセス、フロー、ワークフロー、承認プロセスを確認します。
開発者コンソールで記事タイプオブジェクトへの参照を更新します。	をクリックして、[開発者コンソール] を選択します。 [Edit (編集)] をクリックし、[Search in Files (ファイル内を検索)] をクリックします。 [Search (検索)] 項目に`「_kav」`と入力し、虫眼鏡アイコンをクリックします。この検索によって、記事タイプオブジェクト (*_kav) への参照を含む、組織内の Apex コードのすべてのインスタンスが返されます。移行ツール実行後の検証中に変更を受け入れる前に、コードを更新します。そうしなければ、既存のコードは適切に機能しません。
すべての古い記事タイプの [リリース状況] が [開発中] であることを確認します。	Classic の [設定] で、[クイック検索] ボックスに`「ナレッジ記事タイプ」`と入力し、[ナレッジ記事タイプ] をクリックします。
Knowledge_kav オブジェクトの [リリース状況] が [リリース済み] であることを確認します。	Lightning の [設定] で、[オブジェクトマネージャー] タブに移動し、[ナレッジ] をクリックします。
SOQL を更新します。	複数の記事タイプがある場合、移行ツールによって Knowledge_kav オブジェクトが作成されます。新しいコードは新しい Knowledge_kav オブジェクトを参照する必要があります。また、必要に応じて、コードは適切なレコードタイプ ID で SOQL クエリを絞り込む必要があります。SOQL クエリはレコードタイプではなく、レコードタイプ ID で絞り込む必要があります。レコードタイプ ID は、Sandbox と本番環境では異なる場合があるので、オブジェクト別にレコードタイプの ID を検索するコードを含めてください。理想的なのは、これを再利用可能なユーティリティクラスに入れることです。
検証フェーズで移行した記事を確認します。	ブラウザーで古い記事と新しい記事を比較します。新しい ID と古い ID を照会するには、Postman などの API クライアントを使用します。

Maria はこれらの作業を完了しました。すべてうまく行っているようです。彼女は、何を変更したかをメモします。後で移行プロセスを元に戻すことにした場合は、このリストを使用してこれまでの手順をすべて元に戻すことができます。

次は、メタデータとデータがどのように移行されたかを検証します。移行を受け入れるまでそれらを変更することはできませんが、後で使用するためにメモします。

機能	検証方法
メタデータの設定	[設定] で、[オブジェクトマネージャー] タブに移動し、[ナレッジ] をクリックします。 [項目とリレーション]、[ページレイアウト]、[レコードタイプ] などのページで、ナレッジオブジェクトの詳細がどのように移行されたかを確認します。
データ	新しい [ナレッジ] タブを使用して、移行された記事を表示し、検証します。Maria は、計画時に選んだ代表的な記事のリストを確認します。移行済み Sandbox 組織の記事を Salesforce Classic 本番組織のナレッジの同じ記事と比較し、違いがあればメモします。

Maria の検証作業は正常に完了しました。彼女は Lightning Knowledge 移行ツールの FAQ を読んだので、この時点で移行を元に戻すには数日かかることがあることを知っています。このステップより後には移行を元に戻せないことを知っていますが、準備は整っています。彼女は [Accept (承認)] をクリックします。

[Accept (承認)] をクリックすると、古い記事タイプや Classic バージョン (移行されなかったバージョンを含む) の記事は削除されます。

Maria は移行を完了しました。彼女はプロセスを開始し、結果を検証し、移行を受け入れました。次は移行後の作業を開始します。