移行の計画と Sandbox テスト
Classic 知識ベースの構築に関わったことがあれば、計画を立てることが非常に重要であることはご存知でしょう。実際、計画を立てることは、Lightning Knowledge への移行で最も重要な部分です。
必要なエディション
| 使用可能なインターフェース: Salesforce Classic および Lightning Experience。サポートされているエディションを表示する。 |
Sandbox テスト
本番環境への移行を実行する前に、Sandbox への移行を実行します。Full-Copy Sandbox でテストすることを強くお勧めします。Partial-Copy Sandbox を使用すると、データを破損する可能性が高くなります。Sandbox への移行を実行する手順は、本番環境への移行と同じです。移行の計画を立て、移行前チェックリストを確認した後、1 つの記事タイプの移行か、複数の記事タイプの移行を実行します。
移行前のチェックリスト
ナレッジに 1 つの記事タイプがあるのか、複数の記事タイプがあるのかに関係なく、Sandbox テストを実行する前にチェックリスト全体に目を通してください。
記事タイプ
Classic から Lightning Knowledge に移行するとき、記事タイプは同じ名前の新規レコードタイプに対応付けられます。これらは表示ラベル名ではなく、API 参照名に対応付けられます。移行に進む前に次のチェックを行い、これらの制限に注意してください。
- リリースが取り消された記事タイプを移行する場合、その記事をリリースする。
- 不要な記事タイプを特定して物理削除する。
- [設定] でナレッジ記事タイプのメタデータ設定を変更する。たとえば、記事タイプの追加、記事タイプの削除、記事タイプの設定の変更、または記事タイプへのプロファイルアクセス権の変更など。
- [デフォルトの記事タイプ] 設定を [なし] に変更する。
次の連動関係を削除します。移行ツールが古い記事タイプを無効にしたときに、これらのオブジェクトが削除されず、移行が失敗する可能性があります。
- 他のエンティティによって集計されるエンティティ
- カスタムエンティティ定義を参照するレポートジョブ
- エージェントによる寄稿の設定によって参照される記事タイプ
- アンサーの昇格の設定によって参照される記事タイプ
- 一致ルールによって使用されるカスタムオブジェクト
- 重複ルールによって使用される記事タイプ
- 記事タイプを参照する管理された削除
- 他の管理パッケージの削除できない子カスタム項目を使用する記事タイプ
- 他の機能 (Apex クラスやデータフローなど) によって参照される記事タイプ
現在の組織で作成されたパッケージに記事タイプが含まれている場合、Lightning Knowledge の有効化はブロックされます。Lightning Knowledge を有効にするには、現在の組織で作成されたパッケージから記事タイプを削除します。
ページレイアウト
ユーザーに優れたレイアウト環境と適切な項目へのアクセス権を提供するには、ページレイアウトを調整します。移行後に、レコードタイプまたはユーザープロファイルごとに異なるページレイアウトを再割り当てできます。移行中にページレイアウトが適切に設定されていることを確認します。移行を開始する前に、不要なページレイアウトを削除します。
項目の考慮事項
複数の記事タイプの項目を 1 つのレコードタイプに対応付けるときには、次の考慮事項に注意してください。
- 数式項目は移行されません。移行後、ナレッジオブジェクトに数式項目を作成し、新しいオブジェクトを参照するように数式を修正します。
- 項目の連動関係は移行されません。移行ツールによって項目は移行されます。ただし、項目の連動関係設定は移行されません。
- 選択リストと複数選択リストは、同じ選択リスト値、同じ無効化された値、または同じグローバル選択リストが使用されている場合にのみ対応付けられます。連動選択リストを移行することはできません。選択リストオプションは移行されますが、対応付けは移行されません。移行後にこれらを再設定します。また、選択リストとチェックボックスのデフォルト値は、Lightning Knowledge へは移行されません。ヒント たとえば、組織は A と B という 2 つの選択リスト項目を使用できます。A は制御選択リストで、B は連動選択リストです。移行ツールは、A と B の両方を移行しますが、これらはスタンドアロンの選択リストとなり、項目の連動関係設定を再定義する必要があります。
- 項目を別の項目に対応付けるとき、主項目を指定する選択リストから対象項目を選択します。
- 移行前に項目サイズが縮小されたが、縮小前より記事の文字数が多い場合、すべてのテキストが Classic で表示されます。ただし、移行後、新しいオブジェクトでは項目サイズが切り捨てられます。つまり、追加の文字は表示されません。たとえば、Classic で 500 文字の項目を 1,000 文字に増やした場合、項目に 1,000 文字を入力できても、Lightning ではそのうちの 500 文字しか表示されません。
- 必須項目フラグは移行されません。必須項目はすべて同じテーブル内にあるため、組織ごとに移行後に必須項目を再検討する必要があります。すべてのレコードタイプのすべてのレコードで必要でないかぎり、必須項目はページレイアウトまたは入力規則で管理すべきです。
- 移行された項目は「記事タイプ_項目名」の形式で名前が付けられます。この規則によって項目名の競合が排除されます。
- 削除された項目 (論理削除された項目は 30 日間保持される) は移行されません。
カスタマイズおよび管理 (または未管理) パッケージ
移行前と移行後のカスタム要素を確認して、新しいナレッジオブジェクトに移動されたことを確認します。カスタム要素は破損することがあるので、Sandbox への移行を実行するときに (本番環境への移行前に) 組織のこの側面を評価する準備をしておきます。移行後に、記事タイプを参照するカスタム要素が新しいナレッジオブジェクトを参照するように調整します。
記事タイプが含まれるすべてのパッケージをアンインストールします。これらのパッケージをアンインストールしない場合は、Lightning Knowledge を有効にすることも、Lightning Knowledge 移行ツールを起動することもできません。
パッケージの名前空間が定義されている場合、Lightning Knowledge 移行ツールは、Developer Edition では機能しません。
次に、移行後の評価で検討すべきカスタマイズの例をいくか挙げます。
- 実在のエンティティ名を照会する SOQL
- 古い記事タイプを参照する Visualforce ページ
- 項目セットを使用するコード
- 古い記事タイプを参照する Apex コード
- 記事タイプを参照する API コールを使用するカスタムコード
- 顧客アプリケーションのロジック (現在の API コードなど)
- AppExchange パッケージ
- 入力規則
- CRUD (記事タイプによる)
- 項目セットやコンパクトレイアウトでメタデータ API を使用するアプリケーション
ファイルと添付ファイルに関する考慮事項
Classic ナレッジ記事のカスタムファイル項目のファイルは、標準ファイルオブジェクトに移動されます。移行後、ユーザーは [ファイル] 関連リストでファイルを表示および添付できます。Lightning Knowledge 移行ツールの実行時に、移行された記事に適用する基本の表示設定を選択します。記事にアクセス権を持つすべてのユーザー (ゲストユーザーと Experience Cloud ユーザーを含む) にファイルを表示するか、内部ユーザーのみに表示するかを選択できます。外部ユーザーには共有されないファイルに内部ユーザーがアクセスする必要がある場合、移行後に個々のファイルに対する権限を調整できます。ファイルアクセスを設定する手間を最小限に抑えるには、大部分のファイルに該当する表示オプションを選択します。
移行前のベストプラクティスと移行後の考慮事項
対応付け — スプレッドシートや組織的なツールを使用して、複雑な対応付けのアイデアをまとめます。スプレッドシートまたは組織ツールを使用すると、Lightning でのKnowledgeベースの対応付け方法を把握できます。
検証の準備 — 後で比較して移行の成功を確認できるように、事前に記事をいくつか保存または印刷しておきます。
無効なユーザーが所有するレコード — ナレッジ記事バージョン (kav) が無効なユーザーにリンクされていると、移行中に問題が発生する可能性があります。無効な所有者の記事を正常に移行するには、組織設定の [無効な所有者のレコードを更新] を有効にする必要があります。組織でこの設定が無効になっている場合、移行中に移行ツールによって一時的に有効になります。この設定は、[設定] | [ユーザーインターフェース] にあります。
ケースとアンサーの設定:
- [ケースの設定] の [ケースからの記事の作成をユーザーに許可する] で、[デフォルトの記事タイプ] を [なし] に設定します。
- [アンサーの設定] の [返信からの記事の作成をユーザーに許可する] で、[デフォルトの記事タイプ] を [なし] に設定します。
メンテナンスに関する通知: 本番環境への移行中は知識ベースに関わる活動を停止してください。
データ損失を防止するために、移行中はユーザーが知識ベースを編集しないようにします。複数の記事タイプがある組織では、移行にかかる時間が長く、データモデルが大きく変更されるため、このアクションが特に重要です。移行を開始した後は、できるだけ早くプロセスを完了することが重要です。知識ベースユーザーのダウンタイムを最小限に抑えられるように慎重に計画します。
本番環境への移行を実行する前に、移行中に知識ベース、知識ベースの構造、記事へのすべての変更を停止するように会社全体に通達します。ただし、ユーザーと顧客は移行中も記事を表示することはできます。複数の記事タイプがある組織では、Lightning の記事への切り替えは有効化フェーズの開始時に実行されます。
移行中に停止する必要がある活動の例として、次のものがあります。
- 記事の編集
- 記事の作成
- 記事の公開状況の変更
- ナレッジの設定の変更 (データカテゴリの変更など)
- ナレッジの設定や記事を変更する API コール
- ナレッジ記事を変更または作成する Apex トリガー
- 記事への投票
- ケースへのリンク
- 作業指示または作業指示品目へのリンク
- フィード投稿の追加、フィード投稿の変更、または記事のフォロー
- 記事に添付されたファイルの編集
- Experience Cloud サイトの記事へのトピックの対応付けの追加
Lightning Knowledge 移行ツールの使用準備
計画を立て、Sandbox テストを行った後、Salesforce サポートに連絡し、本番組織での移行を実行する準備が整ったことを伝えます。本番組織でツールを有効にする前に、Sandbox 移行の結果について確認します。あなたの組織は、1 つの記事タイプと複数の記事タイプのどちらを使用していますか?適切なガイドを使用して、Classic から Lightning へ知識ベースを移行します。
