Salesforce のプロファイルは、ユーザーがレコードに対して「実行できる」操作の基盤となり、具体的にはオブジェクトレベルのセキュリティ (作成、読み取り、編集、削除の権限) を定義します。標準のマーケティング ユーザー プロファイルには、通常、デフォルトでは商談オブジェクトへの完全な「編集」アクセスは含まれていません。これは、マーケティング ロールが従来、リードとキャンペーンに重点を置いているためです。マーケターが商談でキャンペーン関係を維持できるようにするには、管理者はプロファイルに必要なオブジェクト権限が付与されていることを確認する必要があります。組織がマーケティング ユーザー テンプレートに基づくカスタム プロファイルを使用している場合は、管理者はそのプロファイル上でオブジェクト権限を直接編集し、商談に対する「読み取り」と「編集」の権限を追加する必要があります。これにより、マーケターはレコードを表示し、「プライマリ キャンペーン ソース」フィールドを更新できるようになります。権限セットでもこのアクセスを付与できますが、この質問は管理者が現在プロファイル自体を構成していることを前提としています。プロファイルのオブジェクト権限を調整することは、ユーザーの機能をビジネスの機能要件に合わせるための直接的な方法です。

Salesforceへのログイン試行回数が多すぎてユーザーがロックアウトされた場合、プラットフォーム管理者はユーザーのレコード詳細ページで特定の操作を実行してアクセスを復元する必要があります。まず、管理者は「ロック解除」ボタンをクリックします。これにより、ロックアウト状態が即座に解除されます。
第二に、ユーザーが認証情報を忘れた可能性が高いため（ログイン失敗の原因）、管理者は「パスワードのリセット」ボタンを使用する必要があります。これにより、ユーザーのメールアドレスに一時的なリンクが送信され、ユーザーは新しいパスワードを作成して正常にログインできるようになります。「ユーザーとしてログインする」（オプションA）は、既存のセッションのトラブルシューティングツールですが、ロックアウトを回避したり、ユーザーに代わってパスワードを変更したりすることはできません。「パスワードポリシーを変更する」（オプションD）は組織全体に影響を与えるため、ロックアウトされた個人を支援する有効な方法ではありません。

リードがアカウント、取引先責任者、商談に変換される際、標準フィールドは自動的にマッピングされます。ただし、カスタムフィールドは、変換プロセスでデータが確実に流れるように手動で設定する必要があります。まず、プラットフォーム管理者は、リードフィールドと同じ値を持つ対応するカスタム選択リストフィールドを取引先責任者オブジェクトに作成する必要があります（オプションB）。次に、管理者はリードオブジェクトマネージャーに移動し、「フィールドとリレーションシップ」を選択して、「リードフィールドのマッピング」をクリックします（オプションC）。ここで、管理者はリードのカスタム選択リストを新しく作成した取引先責任者のカスタム選択リストに明示的にマッピングします。このマッピングを行わないと、変換中にデータが失われます。
検証ルール（オプションA）とフィールドを必須項目にする（オプションD）は、リードにデータが存在することを保証しますが、そのデータを連絡先に転送することを容易にするものではありません。

商談連絡先ロールを使用すると、営業担当者は複数の連絡先を単一の商談にリンクし、「意思決定者」、「影響力者」、「経済的購買担当者」など、それぞれに特定の「ロール」を割り当てることができます。これにより、取引の「購買委員会」を理解するために必要な可視性が得られます。また、「主要連絡先」を指定することもできます。商談チーム（オプションA）は、取引を担当する社内スタッフを追跡するために使用されます。アカウントチーム（オプションB）は、アカウントレベルでのコラボレーションを追跡しますが、取引固有のものではありません。標準フィールド（オプションC）は、商談と複数の連絡先との間の「1対多」の関係を追跡するには不十分です。連絡先ロールは、営業プロセスにおけるステークホルダー管理のために設計された標準機能です。

Salesforce では、承認プロセスにおいてキューを承認者として指定できます。レコードが承認のために送信され、キューにルーティングされると、キューの設定に応じて、すべてのキュー メンバーに電子メール通知が送信されます。基本的な動作は、キューのメンバーであれば誰でもリクエストを「取得」し、承認または拒否できるということです。いずれかのメンバーがアクションを実行すると、ステップは完了とみなされ、キューは単一の意思決定エンティティとして扱われます。全会一致の承認 (オプション A) は、複数の個別の承認者を指定するための特定の設定ですが、この方法ではキューには適用されません。オプション C は、キューの目的がすべてのメンバーに通知して迅速な対応を確保することであるため、誤りです。キューは、ほとんどの標準オブジェクトとすべてのカスタム オブジェクトでサポートされています (オプション D を否定)。