Salesforce 認定 Experience Cloud コンサルタント 1-10

Experience Cloud（旧称：Community Cloud）では、外部ユーザー向けの共有設計が重要なポイントになります。
本問では、顧客本人が自身に関連するケースを継続して参照できる必要があります。
この要件には共有セットが最適です。
共有セットは、ユーザーの参照（例：取引先や取引先責任者）に基づいてレコードアクセスを自動的に付与できる機能です。
そのため、ケースが社内の担当者に割り当てられても、顧客は自分に紐づくケースを引き続き閲覧できます。
Apex共有やOWDは柔軟な反面、開発・管理コストが高く、外部ユーザーへの標準的なアクセス制御には適しません。
スーパーユーザーアクセスは特定ユーザーの権限拡張にすぎず、この要件は満たせません。
以上より、設定のみで実現できる共有セットが正解です。
Experience Cloud サイトユーザー用の共有セットの作成

Experience Cloud（旧称：Community Cloud）では、外部ユーザーの利用範囲に応じて適切なライセンス選択が重要です。
本問のパートナーユーザーはケースの作成・解決やレポート／ダッシュボードの参照が必要ですが、商談やリード管理は不要です。
カスタマーコミュニティプラスは、ケース管理やレポート・ダッシュボード機能など拡張されたアクセス権を提供する外部ユーザー向けライセンスです。
一方、パートナーコミュニティライセンスは商談やリードなどCRM機能全般が必要な場合に適しており、本要件では過剰です。
顧客コミュニティは機能が限定されており、レポートや高度な共有が利用できないため要件を満たしません。
したがって、必要十分な機能を持つカスタマーコミュニティプラスが最適解です。
Experience Cloud ユーザーライセンス

Experience Cloud（旧称：Community Cloud）のパッケージでは、ナビゲーションメニューに関連する依存関係の扱いを理解することが重要です。
カスタムオブジェクトに関連付けられたカスタムリストビューは、パッケージの依存関係として自動的に含まれます。
一方で、標準オブジェクトのカスタムリストビューはパッケージに自動的には含まれず、別途作成や移行が必要です。
そのため、標準オブジェクトのカスタムリストビューは依存関係として含まれない点を考慮する必要があります。
この違いを理解していないと、デプロイ後にナビゲーションリンクが正しく機能しない可能性があります。
以上より、AとBが正解です。
変更セットを使用した完全な Experience Cloud サイトのリリース

Experience Cloud（旧称：Community Cloud）でサイトを別組織へ移行する場合、組織間に接続がないケースでは専用の移行手段を使用する必要があります。
Lightning Bolt ソリューションは、Experience Cloud サイト（テンプレート、ページ、コンポーネントなど）をパッケージとしてエクスポートし、別組織へインストールできる仕組みです。これにより、直接接続されていない環境間でもサイト移行が可能になります。
変更セットやメタデータ API は主に接続された組織間や開発用途向けであり、Experience Cloud サイト全体の移行には適していません。
また、Experience Builder の公開は同一組織内での操作に限られます。
以上より、Lightning Bolt のエクスポートとインストールが正解です。
Lightning Bolt ソリューションの作成

Experience Cloud（旧称：Community Cloud）では、外部ユーザー同士の可視性制御が重要な設計ポイントです。
コミュニティユーザーの可視性設定を使用すると、同一アカウント（パートナー企業）に属するユーザー同士のみが互いを参照・コラボレーションできます。
これにより、別企業の外部ユーザーとの不要な情報共有を防ぐことができます。
一方、Chatterグループは任意メンバーで構成されるため企業単位の制御には適していません。
サイトユーザーやポータルユーザーといった設定は現行のExperience Cloud設計では使用されない、または適切な制御単位ではありません。
したがって、要件を満たすのはコミュニティユーザーの可視性です。
Experience Cloud サイトユーザーが表示できるユーザーの制御

Experience Cloud（旧称：Community Cloud）では、外部システムのコンテンツを統合するための機能が提供されています。CMSコネクトは、外部のコンテンツ管理システム（CMS）と連携し、そのコンテンツをExperience Cloudサイト内に表示できる機能です。
これにより、外部CMSで管理されているヘッダーやフッターなどのコンテンツをそのままポータルにレンダリングすることが可能になります。
他の選択肢はUI設定や開発支援機能であり、外部CMSとの連携機能は提供していません。
したがって、本要件を満たすのはCMSコネクトです。
使用すべき Experience Cloud テンプレートは?

Experience Cloud（旧称：Community Cloud）でライブチャット機能を実装するには、Service Cloud のチャット機能を適切に設定する必要があります。
チャットエージェントのガイド付きセットアップフローは、チャットの有効化、ボタン作成、デプロイ設定などを一連の手順で構成できる推奨方法です。
さらに、エージェントはサービスコンソール上でチャット対応を行うため、この組み合わせが必要となります。
他の選択肢はチャット機能の構成手順として不十分または目的外の機能です。
したがって、チャットエージェントのガイド付きセットアップフローとサービスコンソールが正解です。
埋め込みチャットウィンドウを設定しましょう

Experience Cloud（旧称：Community Cloud）では、外部ユーザーへのレコード共有に共有セットを使用します。
共有セットは、ユーザーの取引先や取引先責任者などの関連情報に基づき、指定したオブジェクトへのアクセスを付与する仕組みです。
そのため、まず共有セットを1つ作成し、対象となるオブジェクトを追加することで、該当ユーザーに対するアクセス制御を実現できます。
共有ルールは内部ユーザー向けの共有機能であり、共有セットとは別の仕組みのため本要件には適しません。
また、「すべてのオブジェクト」オプションやオブジェクトごとの個別作成は適切な方法ではありません。
したがって、正しい手順はAです。
Experience Cloud サイトユーザー用の共有セットの作成

Experience Cloud（旧称：Community Cloud）におけるパートナーコミュニティでは、ロール設計がデータ共有に大きく影響します。
パートナーユーザーのロール数には制限があり、デフォルトで組織あたり最大50,000ロールまで作成可能です。
この制限を考慮しないと、大規模展開時に設計上の問題が発生する可能性があります。
また、ロールは不要になった場合に整理することも重要です。
使用されていないロールは削除可能であり、ロール階層の管理と最適化に役立ちます。
一方で、ロールは削除できないという記述は誤りであり、OWD設定もロール利用の前提条件ではありません。
以上より、AとDが正解です。
Experience Cloud ユーザーライセンス

Experience Cloud（旧称：Community Cloud）では、外部ユーザーの可視性設定によりコラボレーション範囲を制御できます。コミュニティユーザーの可視性を有効にすると、同一アカウント（パートナー企業）に属するユーザー同士のみが相互に参照・共同作業できるようになります。
これにより、他社の外部ユーザーとの不要な情報共有を防ぐことが可能です。
一方、Chatterグループは任意のメンバー構成であり企業単位の制御には適しません。
ポータルユーザーやサイトユーザーといった設定は現行のExperience Cloudでは適切な制御方法ではありません。
したがって、本要件を満たすのはコミュニティユーザーの可視性です。
Experience Cloud サイトユーザーが表示できるユーザーの制御