Salesforce 認定 Platform Sharing and Visibility アーキテクト 1-10

ページレイアウトを変更していないのに項目が表示されなくなった場合は、項目レベルセキュリティ（Field-Level Security）や権限設定の変更が原因である可能性が高いです。
Field Accessibility を確認すれば、プロファイルや権限セットごとに、その項目が参照・編集可能かどうかを横断的に把握できます。
「Who Sees What」レポートはレコード共有状況の確認機能であり、項目の表示制御の調査には向きません。
複数ユーザーでログインして確認する方法も現象把握はできますが非効率です。
そのためField Accessibility を用いて調査する方法が最も適切といえます。
特定の項目に対するアクセス権の検証

リードの編集・再割り当てを所有者のみに限定するには、OWD を Private に設定するのが最も適切です。
Private では、レコード所有者と上位ロールのユーザーのみが標準でアクセスでき、不要な編集権限を防げます。
これにより複数ユーザーによる重複登録や不要な更新も抑えやすくなります。
Public Read Only/Transfer は転送権限まで広く与えてしまい、Public Read-Only も参照範囲が広いため、所有者だけに編集・再割り当てを限定する要件を満たせません。
組織の共有設定

同じ代理店内の他パートナーユーザーが持つレコードへ、パートナーマネージャーロールのユーザーが広くアクセスできるようにするには、Super User 権限を付与する方法が最適です。
Super User アクセスは、外部ユーザーが同一取引先配下のユーザーの所有・共有レコードを参照できる仕組みで、代理店単位の可視性拡張に適しています。
所有者ベースの共有ルールは代理店数が多いと管理が煩雑になり、共有セットは主に取引先・取引先責任者との関係に基づくアクセス付与であるため、同一代理店内の上位ユーザーへ広範な可視性を与える要件には Super User の方が適しています。
パートナーユーザーとカスタマーユーザーへのポータルスーパーユーザーアクセスの付与

高リスク商品を扱える担当者を限定するには、Price Book へのアクセス権を適切に制御することが重要です。
Price Book の OWD を View Only に設定したうえで、共有ルールを使って対象グループに高リスク用 Price Book を共有すれば、研修済みの担当者だけがその商品価格を用いて商談を作成できます。
手動共有は対象者が増えるほど管理負荷が高くなり、継続運用には向きません。
したがって、共有ルールを用いて自動的かつ拡張性の高いアクセス制御を行う方法が最適です。
価格表の共有に関するガイドライン

商談チームで Read/Write 権限を付与されたユーザーは、対象商談の閲覧と編集が可能になります。
そのため、商談のステージや金額、完了予定日などの項目を更新できます。
一方、商談所有者の変更や商談チームメンバーの追加・削除は、通常は所有者やより高い権限を持つユーザーに限定される管理操作です。
したがって、Read/Write 権限だけで実行できるのは商談ステージの更新です。
取引先または商談チームメンバーのインポート時のアクセスレベルの指定

Contact の共有設定が Controlled by Parent の場合、Contact へのアクセス権は親オブジェクトである Account のアクセス権に従って決まります。
Case には implicit sharing により関連する Account への参照権限が伴うため、サービス担当者は業務上必要な Account にアクセスでき、それに連動して関連 Contact にもアクセスできるようになります。
Case への View All 権限自体が Contact への直接権限になるわけではありませんが、この親子関係に基づく共有モデルを理解しておくことが重要です。
したがって、Contact が Controlled by Parent であれば、Account 経由で Contact も参照できる点を考慮すべきです。
Apex共有理由を作成する

Salesforce のロール階層では、上位ロールのユーザーは下位ロールのユーザーが所有するレコードへ自動的にアクセスできます。
オペレーションユーザーがマネージャーの配下ロールに配置されていれば、オペレーションマネージャーはチームが所有する予定済みコースを閲覧・編集できます。
追加の共有ルールや公開グループの作成は不要で、管理負荷も最小限に抑えられます。
したがって、既存の組織構造に沿ってロール階層を活用する方法が最も標準的かつ拡張性の高い解決策です。
テリトリーへの取引先とリードの手動割り当て

営業担当者が都度手作業で支援部門へアクセスを共有する負担を減らすには、Default Account Team を利用し、定型的な支援メンバーを自動的に追加する方法が最適です。
営業担当者ごとに法務・技術・財務の担当者を既定チームとして登録しておけば、取引先の作成・更新時に自動的に共有されます。
条件ベース共有ルールは個別の柔軟な体制に対応しにくく、View All Data は権限が広すぎます。
したがって、業務効率と最小権限の両立ができる Account Team の活用が最善策です。
ユーザーレコードにデフォルトの取引先または商談チームを追加する

現場コンサルタントがモバイル端末で撮影した写真を Case に紐づけて管理するには、Salesforce Files を利用してアップロードし、Case レコードへ関連付ける方法が最適です。
Files はモバイル・デスクトップの両方から利用しやすく、プレビューや共有、バージョン管理にも対応しています。
標準添付ファイル（Attachment）は旧機能であり、現在は Files の利用が推奨されています。
したがって、将来性・操作性・管理性の観点から Salesforce Files を活用する設計が最善です。
Salesforceファイルの扱いについて

要件は、モバイル利用者にだけ写真撮影機能を提供しつつ、デスクトップ利用者には既存の Lightning 編集画面をそのまま使い続けてもらうことです。
そのため、モバイル表示に限定して Edit アクションを Lightning コンポーネントで上書きする方法が最適です。
これにより、現場コンサルタントは編集時にカメラ連携で写真を取得でき、デスクトップ利用者の操作フローには影響しません。
端末判定とリダイレクト処理を伴う方法は複雑化し、新しいボタンを追加する方法は操作導線の教育や保守負担が増えます。
したがって、最小限のカスタマイズで既存 UI を維持できる方法が最善策です。
標準アクションの上書き