Q1.Universal Containers のユーザーから、先週末のデプロイ後に Account ページからある項目が消えたとの苦情が出ています。
今回のデプロイではページレイアウトの変更はありませんでした。
管理者はこの問題をどのように調査すべきですか。
A. Account を条件にして「Who Sees What」レポートを実行する。
B. 3人のユーザーとしてログインし、複数の取引先を確認して問題のレコードを特定する。
C. オブジェクトマネージャで Field Accessibility（項目アクセス性）を確認する。
回答
- C. オブジェクトマネージャで Field Accessibility（項目アクセス性）を確認する。
-
ページレイアウトに変更がないにもかかわらず項目が表示されなくなった場合、原因として最も可能性が高いのは 項目レベルセキュリティ（Field-Level Security）や権限設定の変更 です。Field Accessibility を確認すると、各プロファイルや権限セットごとに、その項目が参照可能か編集可能かを横断的に確認できます。
A の「Who Sees What」レポートはレコード共有状況を確認する機能であり、項目の表示制御確認には適していません。
B は現象確認には有効ですが、根本原因の特定には非効率です。したがって、Field Accessibility を使って項目の可視性を調査する方法が最適 です。
特定の項目に対するアクセス権の検証
Q2.Universal Containers（UC）は、システムに登録される重複したリードの数を減らしたいと考えています。
また、リードはリード所有者のみが編集または再割り当てできるようにしたいと考えています。
これらの要件を満たすために、どの組織全体のデフォルト設定（OWD）を推奨すべきですか。
A. リードに対して Public Read Only/Transfer の OWD を設定する。
B. リードに対して Public Read-Only の OWD を設定する。
C. リードに対して Private の OWD を設定する。
回答
- C. リードに対して Private の OWD を設定する。
-
リードを所有者のみが編集または再割り当てできるようにするには、OWD を Private に設定することが最も適切 です。
Private では、レコード所有者と上位ロール階層のユーザーのみが標準的にアクセスでき、不要な編集権限を制限できます。
これにより、複数ユーザーによる重複登録や不適切な更新も抑制しやすくなります。
A の Public Read Only/Transfer は転送権限が広く、B の Public Read-Only も閲覧範囲が広いため、所有者だけに編集・再割り当てを限定する要件を完全には満たしません。
組織の共有設定
Q3.Universal Containers（UC）には、Partner Community ライセンスを使用する200社の販売代理店があります。
パートナーは互いのデータを見ることはできませんが、UC は販売代理店内の特定の個人に対して、より多くのデータ可視性を付与したいと考えています。
同じ販売代理店のパートナーユーザーに関するすべてのケースおよびコンテナレコードへのアクセスを、パートナーマネージャーロールのユーザーに付与する拡張性のある選択肢はどれですか。
A. 所有者ベースの共有ルールを作成する。
B. 個々のパートナーマネージャーユーザーに Super User 権限を付与する。
C. 共有セットを作成する。
回答
- B. 個々のパートナーマネージャーユーザーに Super User 権限を付与する。
-
パートナーマネージャーロールのユーザーに、同じ取引先に属する他のパートナーユーザーのレコードへ広くアクセスさせるには、Super User 権限を付与することが最も適切です。
Super User アクセスは、外部ユーザーが同じ取引先配下のユーザーが所有または共有されたレコードを参照できるようにする仕組みで、販売代理店単位での可視性拡張に向いています。
所有者ベースの共有ルールは多数の販売代理店に対して管理が複雑になりやすく、共有セットは主にユーザーと取引先や取引先責任者との関係に基づくアクセス付与であり、同一販売代理店内の上位ユーザーに広範な可視性を与える要件には Super User 権限の方が適しています。
パートナーユーザーとカスタマーユーザーへのポータルスーパーユーザーアクセスの付与
Q4.Universal Containers は Sales Cloud を導入しており、高リスク商品を販売するための訓練を受けた特定の支店スタッフのみが、高リスク商品の商談を作成できるようにしたいと考えています。
アーキテクトはどのようにして、特定の支店スタッフのみに高リスク商品の販売を許可すべきですか。
A. 価格表（Price Book）の OWD を View Only に設定し、手動共有で高リスク価格表を訓練済みスタッフに共有する。
B. 価格表（Price Book）の OWD を View Only に設定し、共有ルールで高リスク価格表を訓練済みスタッフに共有する。
C. 価格表（Price Book）の組織全体のデフォルト設定（OWD）を View Only にし、高リスク価格表を訓練済みスタッフに共有する。
回答
- B. 価格表（Price Book）の OWD を View Only に設定し、共有ルールで高リスク価格表を訓練済みスタッフに共有する。
-
高リスク商品の商談を作成できるユーザーを限定するには、Price Book のアクセス権を制御することが重要です。
Price Book の OWD を View Only に設定し、必要なユーザーグループに対して共有ルールで高リスク用 Price Book を共有すれば、訓練済みスタッフのみがその商品価格を利用した商談作成を行えます。
手動共有は管理負荷が高く継続運用に不向きです。
したがって、共有ルールを用いて対象スタッフへ自動的かつ拡張性の高いアクセス制御を行う方法が最適です。
価格表の共有に関するガイドライン
Q5.Universal Containers の営業担当者が、Read/Write 権限付きで商談チームに追加されました。
彼女はその商談に対して、どの操作を実行できますか。
A. 商談ステージを更新する。
B. 商談所有者を変更する。
C. 商談チームのメンバーを追加または削除する。
回答
- A. 商談ステージを更新する。
-
商談チームで Read/Write 権限を付与されたユーザーは、対象商談の閲覧と編集が可能になります。
そのため、商談ステージや金額、完了予定日など商談項目の更新を行うことができます。
一方で、商談所有者の変更や商談チームメンバーの追加・削除は、通常は所有者またはより高い権限を持つユーザーに限定される管理操作です。
したがって、Read/Write 権限のみで実行できる操作は商談ステージの更新 です。
取引先または商談チームメンバーのインポート時のアクセスレベルの指定
Q6.Universal Containers（UC）のサービス担当者には、Case オブジェクトに対して View All 権限を持つプロファイルが割り当てられています。
Account オブジェクトと Case オブジェクトの組織全体のデフォルト設定（OWD）は Private です。
サービス担当者が顧客対応に必要な関連情報（Account と Contact）へアクセスできるようにするため、アーキテクトはどの点を考慮すべきですか。
A. Account の OWD が Private の場合、サービス担当者は関連する Account にアクセスできない。
B. Contact の OWD が Controlled by Parent の場合、サービス担当者は関連する Contact にアクセスできない。
C. Contact の OWD が Controlled by Parent の場合、サービス担当者は関連する Contact にアクセスできる。
回答
- C. Contact の OWD が Controlled by Parent の場合、サービス担当者は関連する Contact にアクセスできる。
-
Contact の共有設定が Controlled by Parent の場合、Contact へのアクセス権は親オブジェクトである Account のアクセス権に従って決定されます。
そのため、サービス担当者が業務上必要な Account にアクセスできれば、関連する Contact にもアクセス可能になります。Case に View All 権限があっても、それ自体が Contact への直接権限になるわけではありませんが、親子関係による共有モデルを理解することが重要です。
したがって、Contact が Controlled by Parent であれば、関連 Account へのアクセスを通じて Contact も参照できる点を考慮すべきです。
Apex共有理由を作成する
Q7.Universal Containers（UC）は、500 の異なる地域で研修を提供しています。
UC のオペレーションユーザーチームは、コース設定、スケジュール管理、講師設定を担当しています。
チームメンバーは地域単位で勤務し、オペレーションマネージャーに報告しています。
オペレーションマネージャーは、オペレーションユーザーチームが所有するすべての予定済みコースを編集できるアクセス権を求めています。どのように実現すべきですか。
A. 所有者ベースの共有ルールを作成し、予定済みコースをオペレーションマネージャーへ共有する。
B. ロール階層で定義されたオペレーションユーザーチームが所有する予定済みコースへのアクセス権を、オペレーションマネージャーが取得する。
C. 公開グループを作成し、オペレーションマネージャーとオペレーションユーザーチームをその公開グループへ追加する。
回答
- B. ロール階層で定義されたオペレーションユーザーチームが所有する予定済みコースへのアクセス権を、オペレーションマネージャーが取得する。
-
Salesforce のロール階層では、上位ロールのユーザーは下位ロールのユーザーが所有するレコードへ自動的にアクセスできます。そのため、オペレーションユーザーがマネージャー配下のロールに配置されていれば、オペレーションマネージャーはチーム所有の予定済みコースを閲覧・編集できます。
追加の共有ルールや公開グループを作成する必要がなく、管理負荷も最小限です。
したがって、組織構造に沿ってロール階層を利用する方法が最も標準的かつ拡張性の高い解決策です。
テリトリーへの取引先とリードの手動割り当て
Q8.Universal Containers（UC）の営業担当者は、顧客レコードにアクセスする際、法務・技術・財務などの社内支援ユーザーへ都度アクセス権を付与する手作業が多く、生産性低下に不満を持っています。
通常、案件に関わる営業担当者は頻繁には変わりません。
アーキテクトは営業担当者の生産性をどのように改善すべきですか。
A. 他ユーザーへアクセス権を付与する条件ベース共有ルールを作成する。
B. デフォルトの Account Team を活用する。
C. View All Data 権限を持つ権限セットを作成し、支援ユーザーへ割り当てる。
回答
- B. デフォルトの Account Team を活用する。
-
営業担当者が毎回手動で支援部門へアクセス共有する負担を減らすには、Default Account Team を利用して定型的な支援メンバーを自動追加する方法が最適です。
営業担当者ごとに法務・技術・財務担当者を既定チームとして設定しておけば、取引先作成時や更新時に必要なメンバーへ自動的に共有できます。
条件ベース共有ルールでは個別の柔軟な担当体制に対応しにくく、View All Data は権限が広すぎます。
したがって、業務効率と最小権限の両立ができる Account Team の活用が最善策です。
ユーザーレコードにデフォルトの取引先または商談チームを追加する
Q9.あるコンサルティング会社は、現場コンサルタント向けに Salesforce モバイルアプリを使用しており、Case オブジェクトで顧客ごとの現場コンサルティング業務を管理しています。
また、多数のカスタマーサービス担当者は会社支給のデスクトップ端末から顧客対応を行い、Case オブジェクトで問い合わせや苦情を管理しています。
会社は、現場コンサルタントが Case を更新している間に撮影した顧客現場の画像を取得したいと考えています。
これらの要件をどのように実装するのが最適ですか。
A. Salesforce モバイルアプリで Case の標準添付ファイル機能を使用する。
B. Salesforce Files を利用し、モバイルから画像をアップロードして Case に関連付ける。
C. デスクトップユーザー用に別カスタムオブジェクトを作成し、画像を保存する。
回答
- B. Salesforce Files を利用し、モバイルから画像をアップロードして Case に関連付ける。
-
現場コンサルタントがモバイル端末から撮影した画像を Case に紐づけて管理するには、Salesforce Files を利用して画像をアップロードし、Case レコードへ関連付ける方法が最適です。Files はモバイル・PC の両方から利用しやすく、プレビュー、共有、バージョン管理にも対応しています。
標準添付ファイル（Attachment）は旧機能であり、現在は Files の利用が推奨されています。
したがって、将来性・操作性・管理性を考慮すると Salesforce Files を活用する設計が最善です。
Salesforceファイルの扱いについて
Q10.あるコンサルティング会社は、現場コンサルタント向けに Salesforce モバイルアプリを使用し、Case オブジェクトで顧客ごとの現場コンサルティング業務を管理しています。
また、多数のカスタマーサービス担当者は会社支給のデスクトップ端末から Case オブジェクトで問い合わせや苦情を管理しています。
会社は、現場コンサルタントが顧客先で Case レコードを編集中に撮影した画像を取り込みたいと考えています。
IT 部門責任者は、カスタマイズを最小限に抑えつつ、顧客対応担当者がこれまでと同じ Lightning ページを使い続けられることを望んでいます。
アーキテクトはどの提案を行うべきですか。
A. モバイル表示のみで Edit アクションを Lightning コンポーネントで上書きし、画像取得機能を提供する。デスクトップユーザーには変更しない。
B. Lightning Experience の Edit アクションを Lightning コンポーネントで上書きし、画像取得機能を提供する。端末種別を判定してモバイル以外は標準編集画面へリダイレクトする。
C. 「Edit in Mobile」という別ボタンを作成し、画像追加用カスタム Lightning コンポーネントを起動する。デスクトップユーザーには変更しない。
回答
- A. モバイル表示のみで Edit アクションを Lightning コンポーネントで上書きし、画像取得機能を提供する。デスクトップユーザーには変更しない。
-
要件は、モバイル利用者だけに画像撮影機能を提供しつつ、デスクトップ利用者には既存の Lightning 編集画面をそのまま維持することです。
そのため、モバイル環境の Edit アクションのみを Lightning コンポーネントで上書きする方法が最適です。
これにより、現場コンサルタントは編集時にカメラ連携で画像取得でき、PC 利用者の操作フローには影響しません。
B は端末判定やリダイレクト処理が必要で複雑化し、C は新しい操作導線の教育や保守負担が増えます。
したがって、最小カスタマイズかつ既存 UI を維持できる A が最善策です。
標準アクションの上書き
