移行の計画
学習の目的
この単元を完了すると、次のことができるようになります。
- Lightning Knowledge への移行中に何が変更されるかを説明する。
- Lightning Knowledge への移行に対して自社の準備ができているかどうかを判断する。
- 移行の計画を立てる。
移行中の変更
開始する前に Maria は、Lightning Knowledge 移行ツールがどのように移行プロセスの自動化に役立つかについて調査します。このツールは 2 種類の移行に対応しています。1 つの記事タイプを使用する知識ベースの移行と複数の記事タイプを使用する知識ベースの移行です。Ursa Major では 2 つの記事タイプを使用しているため、彼女は複数の記事タイプを使用する移行に絞って調査します。
次の表では、複数の記事タイプでの機能を比較しています。
| 機能 | 移行中 | 移行後 |
|---|---|---|
| データモデルと記事タイプ | 移行ツールによって、記事タイプがレコードタイプに変換され、項目が 1 つの Lightning Knowledge オブジェクトに統合されます。また、ケースへのリンク、データカテゴリ、投票、ビュー、記事フィードなどの関連レコードの移動と統合も行われます。 | ナレッジでは、レコードタイプごとに機能が管理されます (ページレイアウトを含む)。 |
| 記事番号 | ハードコードされたアプリケーションの標準自動採番データ型に関する制限により、記事番号が変更されます。 | 新しい記事番号を使用します。 |
| ファイル | 移行ツールによって、記事のカスタムファイル項目から標準ファイルオブジェクトにファイルが移動されます。移行後は、すべてのファイルに使用する基本表示設定を選択できます。この設定により、記事へのアクセス権を持つすべてのユーザー (ゲストユーザーと Experience Cloud ユーザーを含む) にファイルが表示されるか、内部ユーザーのみに表示されるかが決まります。 | システム管理者とユーザーは、[ファイル] 関連リストでファイルを表示および添付します。必要に応じて、個々のファイルの表示設定を変更します。 |
| 権限 | 作成権限を定義する方法として記事アクションはサポートされなくなりました。 | システム管理者は、ユーザープロファイルと権限セットを設定して記事へのアクセス権を制御します。 |
| ページレイアウト | 自動的に移行されます。 | システム管理者は、ページレイアウトの確認と編集を行います。ページレイアウト設定を使用して、ページレイアウトに対する項目の選択、アクションの追加、関連リストの追加を行います。ページレイアウトの割り当てを使用して、レコードタイプまたはユーザープロファイルごとにページレイアウトを割り当てます。 |
| モバイルページ用のコンパクトレイアウト | 移行されます。 | Lightning Knowledge では、コンパクトレイアウトはモバイルに限らずすべてのページで機能します。レコードタイプごとに設定することもできます。 |
Lightning Knowledge 移行ツールによって、面倒な作業のほとんどが自動で実行されます。ただし、Maria は、移行前と移行後にナレッジ組織を設定するいくつかの作業を行う必要があります。
移行の適切なタイミング
Maria は既存の知識ベースを評価して、移行に適しているかどうかを確認します。移行が可能であり、サービスチームが使用する機能が移行後も機能することを確認する必要があります。
彼女は、チームが使用している機能とその実装方法を確認します。Lightning Knowledge は Classic とは異なるため、サービスチームが Lightning Knowledge で使用できない機能に依存している場合、移行は賢明ではありません。
背景をしっかり把握するために、Maria は移行に関するヘルプトピックを読みます。プロセスを進めていくときにも再び読むつもりですが、開始前に多くのことを知っておきたいと考えています。
- AppExchange アプリケーションを確認する。移行前に Maria は、チームが使用するアプリケーションが Lightning Knowledge で使用できることを確認します。移行後にはテストを行う必要があります。
- 移行後に項目を再作成する。移行後には、もう一度設定を行う必要があります。移行されない項目には、数式、連動選択リスト、カスタムコードなどがあります。完全なリストについては、「Lightning Knowledge 移行ツールの機能と考慮事項」を参照してください。移行後にそれらを再作成できるかというと、はい。Maria にとってそれが大変な作業かというと、答えはノーです。
- カスタマイズを更新する。たとえば、数式や Apex コードを含む Visualforce ページなどです。Maria は、これらのカスタマイズが引き続き必要かどうかを判断します。必要であれば、カスタマイズのための新しい方法を利用して、Lightning コンポーネントを構築します。
- サポートされる機能を使用する。Maria はチームがサポートされない機能を使用していないことを再確認します。詳細は、「Lightning Knowledge の制限事項」を参照してください。
彼女は、サービスチームと共に制限事項と変更事項のリストを確認します。移行を決定する前に、Lightning Knowledge で動作が異なる事項について理解しておくことが重要です。慎重に検討した後、移行が望ましいということに全員が同意しました。
移行前のチェックリストの作成
Maria は最初のリストの作成を開始します。彼女はリスト好きです。自分の ToDo リストに「ToDo リストを作成する」という項目を追加するほどです。そうすれば、完了したときに項目を消すことができますからね。彼女は、ドキュメントに「移行前のチェックリスト」が含まれていることを知って喜びました。
チェックリストの最初のヒントとして、まずフルコピーの Sandbox に移行を実行することが推奨されています。その後、Sandbox で完璧に機能することをテストして確認することができます。それが完了すると、本番組織への移行を行います。つまり、Sandbox 組織への移行と本番組織への移行の 2 回の移行を行います。本番組織に移行するときまでには、移行をスムーズに進められるようになっているでしょう。
Maria は、自分のリストを作成するのに十分な背景知識を得られたと感じました。
Ursa Major の移行前チェックリストは次のとおりです。
| コンポーネント | 移行前に実行する作業 |
|---|---|
| 記事タイプ |
|
| 権限 |
|
| ページレイアウト |
|
| 項目 |
|
| 移行されないカスタマイズ | Ursa Major では複数の記事タイプを使用しているため、Maria はそれらの記事タイプを参照するカスタマイズを探します。次に、いくつかの一般的な例を示します。
|
| AppExchange アプリケーション | AppExchange アプリケーションが Lightning Knowledge で機能することを確認します。Ursa Major が使用している AppExchange アプリケーションは 1 つで、そのアプリケーションには Lightning Knowledge との互換性があります。 |
| ケースとアンサーの設定 | 移行中のエラーを避けるために、次のことを実行します。
|
| 記事 | 移行を開始する前に、スケジュールされた記事を公開およびアーカイブします。 |
| 自分がナレッジユーザーであることの確認 | Maria は、移行を実行する組織で「すべてのデータの編集」権限があるナレッジユーザーである必要があります。 |
| 移行中の組織への変更の停止 | 移行の進行中にユーザーが知識ベースを変更すると、データが失われたり破損したりする可能性があります。[ナレッジ記事アクション] で、Maria はシステム管理者以外のユーザープロファイルの記事に対する「作成」、「編集」、「アーカイブ」、「削除」権限を削除します。Sandbox に移行する場合は、移行が完了した後に本番組織のそれらの権限を元に戻すことができます。本番組織に移行する場合は、それらのアクションを権限セットに置き換えます。 |
これで、Maria は移行に必要な作業の範囲について理解を深めることができました。
また彼女は、本番組織を Lightning Knowledge に移行するには、Salesforce サポートに許可を申請する必要があることに気付きました。Sandbox 移行の直後に申請する予定です。そうすると、約 1 週間後に本番組織の移行を開始する準備が整います。
Maria は、移行を開始することにワクワクしています。移行はピーク時間外に行う必要があるため、チームに連絡し、金曜日の午後 7 時以降が最適な時間であることを知りました。これで、移行開始前に完了する作業の詳細な計画ができました。あとは金曜日の夜に開始するのを待つだけです。
