Salesforce 認定 Agentforce Sales コンサルタント 1-10

本問はプライベート共有モデルで商談へのアクセス権をどう付与するかが論点です。
プライベート設定では、レコードは所有者と共有されたユーザーのみが閲覧できます。
そのため、プロダクトマネージャーに商談を見せるには共有設定の追加が必要です。
選択肢Cの条件に基づく共有ルールを使えば、製品などの条件に一致した商談へ自動的にアクセス権を付与できます。
コード開発なしでスケーラブルにアクセス権を付与できる点が重要です。
一方でトリガー（B・D）は開発が必要となり、宣言的機能で満たせる要件には不向きです。
Salesforceではまず宣言的機能（共有ルール）を優先する設計原則がある点も重要です。
共有ルールタイプ

「ファネルの管理」は、商談が各ステージをどのように進み、どこで停滞しているかを把握し、将来の売上を見通すことが目的です。
そのためステージごとの滞留状況や、今後の見込みを示す予測情報が重要になります。
Aの「ステージ滞在期間の推移」は各ステージでの滞在時間を可視化でき、「営業担当者別の売上予測」は将来の売上見込みを示します。
ファネルの健全性（滞留・進捗）と将来予測の両方をカバーできる点が重要です。
一方でBはリード分析、Cは活動量や件数把握にとどまり、ファネル全体の流れや予測管理には直結しません。
ファネル管理では「ステージの流れ」と「予測」の可視化が最重要である点を押さえておきます。
商談フェーズの期間に関するレポートを作成

本問は「特定の条件（ステージがクローズ/受注以降）」のときだけ編集を制限する方法が問われています。
フィールドレベルセキュリティは常に編集可否を固定するもので、条件付き制御はできません。
検証ルールを使えば、「ステージが特定の条件のときは保存自体を拒否する」という制御が可能です。
条件に応じて保存をブロックできる点が重要です。
ワークフロールールは更新処理のための仕組みであり、入力を止める用途には適していません。
Salesforceでは条件付きの入力制御は検証ルールで実現するのが基本設計である点が重要です。
検証ルール

Salesforce for Outlookでは、ユーザーは手動と自動の両方の方法でデータ同期を実行できます。
Aの「今すぐ同期」はユーザーが任意のタイミングで即時に同期を行う手動操作です。
ユーザー主導でいつでも同期を実行できる点が重要です。
Dのバックグラウンド同期は、設定に基づいて定期的に自動実行されます。
ユーザー操作なしで継続的に同期が維持される点が重要です。
BやCのように個別にスケジュールを細かく設定する仕組みはなく、手動同期と自動（バックグラウンド）同期の2種類で管理されます。
なお、Salesforce for Outlookは提供終了となっており、現在はOutlook統合やEinstein Activity Captureへの移行が案内されています。
Salesforce for Outlook(引退)とMicrosoft® Outlook®間の同期

本問は分割払い（長期契約の収益）をどのように管理・予測するかがポイントです。
Sales Cloudでは「収益スケジュール」を利用することで、売上を期間ごとに分割して管理できます。
収益スケジュールを使うと、各支払いのタイミングや金額を設定でき、長期契約における収益認識が可能になります。
月次などの期間単位で収益を分割し、将来の売上予測へ活用できる点が重要です。
他の選択肢は単なるデータ保持や処理の自動化にとどまり、財務予測には不十分です。
収益タイミングの管理と予測精度の向上には、標準機能である収益スケジュールの活用が最適である点が重要です。
商品スケジュール

Salesforceの資産（Asset）は、必ずしも自社が販売した製品だけに限定されるものではありません。
資産は顧客が所有する製品や設備を記録するためのオブジェクトであり、他社製品や外部で取得した製品も登録できます。
そのため、「自社が販売したものしか追跡できない」という記述は誤りです。
資産は顧客が所有するあらゆる製品を管理できる点が重要です。
資産はサポートや保守、アップセルなどにも活用されるため、販売元に依存せず管理できる設計になっています。
顧客を中心としたデータモデルである点が重要なポイントです。
Field Service での納入商品の管理と最適化
商品/納入商品レポート

本問は「モバイル活用が実際に行われているか」をどう示すかがポイントで、単なる設定確認ではなく実利用の証拠が求められます。
Aのようにモバイルから作成された商談をレポートすれば、営業担当者が実際にモバイルを使って商談を進めていることを示せます。
実際の業務データに基づいて利用状況を可視化できる点が重要です。
Bのログイン情報だけでは利用状況の一部しかわからず、Cは設定確認にすぎません。
導入効果を示すには「利用実績データ」を提示することが最も重要である点がポイントです。
Salesforce for Android and iOS アプリケーションからモバイルログインを追跡する

本問は異なるリード種別ごとに異なる業務プロセスを適用する設計が問われています。
Salesforceでは「レコードタイプ」と「リードプロセス」を組み合わせて実現します。
まずCのレコードタイプで「ディストリビューター」と「小売業者」を区分します。
次にAのリードプロセスで、それぞれに異なるステータスの流れを定義します。
さらにEで各プロセスに対応したステータス選択リスト値を設定します。
レコードタイプ・プロセス・選択リストの組み合わせで業務を分岐させる点が重要です。
Bは不要な制約を生み、Dはプロセス制御とは無関係です。
複数のビジネスプロセスの管理

本問は「通知の柔軟性」と「ユーザーごとの通知制御」がポイントです。
ワークフロールールによるメール通知は一律配信となり、ユーザーごとの頻度調整ができません。
Chatterを利用すると、レコードをフォローすることで更新通知を受け取れ、ユーザー自身が通知頻度（即時・日次など）を設定できます。
ユーザーごとに通知頻度を柔軟に制御できる点が重要です。
関心のある商談だけをフォローすれば必要な更新のみを受信でき、情報過多も防げます。
フォロー機能により関心のあるレコード単位で通知を最適化できる点が重要です。
フォロー・レコード

本問はプロジェクト手法の選定が問われており、要件として「迅速な反復」「頻繁なフィードバック」「継続的な改善」が求められています。
アジャイルは短い開発サイクル（スプリント）で反復的に開発し、都度フィードバックを取り入れて改善していく手法です。
頻繁なアップデートと柔軟な要件変更への対応ができる点が重要です。
一方でウォーターフォールは要件固定型で変更に弱く、カンバンは可視化には強いものの本問のような反復開発プロセスの主軸にはなりません。
Salesforce導入では反復・適応型のアジャイルが標準的に採用される点が重要です。
Salesforce がアジャイルを採用した理由の理解