Administrator 練習問題 Q145
Cloud Kicks のプラットフォーム管理者は、財務チームから、一定額を超える成立商談について、商談が完全に成立したとみなされる前に、正確性を確認するよう依頼を受けました。担当の財務チームメンバーと営業担当マネージャーの両方が、まずマネージャーが承認を行い、その後財務チームメンバーが承認する必要があり、商談ごとに最大 3 人が承認する必要があります。管理者はこの依頼にどのように対応すべきでしょうか。
左の○で回答を選択。本文を押すと横線で除外でき、もう一度押すと戻せます。
1つ選択してください（0/1）
正答：D. 特定の手順を含む承認プロセスを作成します。
解説
前提知識
承認プロセスとは
承認プロセスは、レコードを特定のユーザーへ回し、承認または却下の判断を記録する仕組みです。単に通知するのではなく、誰がいつ判断したかを履歴として残し、承認結果に応じて後続処理を実行できます。
承認ステップとは
承認ステップは、承認プロセス内の個々の審査段階です。各ステップで、次の内容を定義します。
- どの条件でそのステップへ進むか
- 誰が承認するか
- 前のステップが完了した後に開始するか
- 承認・却下後に何を行うか 本問の「マネージャーが先、その後に財務担当」という要件は、承認ステップを順番に配置することで実現します。
💡 承認プロセスと承認ステップの関係がまだモヤッとする方へ→ 承認プロセスとは何か：「上司の承認をもらう」を仕組み化する
通知と承認の違い
メールを送るだけでは、受信者が承認したか、却下したか、誰の判断待ちかをSalesforce上で統制できません。順番・担当者・判断履歴を管理する要件では、承認プロセスを使用します。
設問の状況を分解する
- 一定額を超える成立予定の商談は、最終的に成立とみなす前に確認が必要
- 営業担当のマネージャーが最初に承認する
- マネージャーの承認後、財務チームの担当者が承認する
- 商談によっては最大3人の承認者が関与する
- 承認者へ知らせるだけでなく、順番を強制して判断結果を残す必要がある 決め手は、複数の人が決められた順番で承認することです。この要件に直接対応するのが、複数の承認ステップを持つ承認プロセスです。
選択肢の検討
A. 商談がクローズされるたびに実行される画面フローを作成します。 → ✕
画面フローは、ユーザーに入力画面を表示しながら処理を進める機能です。商談がクローズされるたびに実行するだけでは、マネージャーと財務担当へ順番に承認依頼を送り、各判断を承認履歴として管理できません。 また、本問では商談が完全に成立したとみなされる前に承認が必要です。クローズ後に画面フローを起動する設計では統制のタイミングも合いません。 この選択肢が適するのは、担当者に追加情報を対話形式で入力させたい場合です。
B. 承認レコードの詳細を取得するには、商談ページに Lightning Web コンポーネントを追加します。 → ✕
Lightning Webコンポーネントは画面表示をカスタマイズする技術です。既存の承認情報を表示することはできますが、承認の順序、承認者、進行条件を定義するプロセスそのものにはなりません。 この選択肢が適するのは、すでに構築済みの承認状況を独自UIで見せたい場合です。
C. マネージャーと財務チームのメンバーの両方にメールを送信するクイックアクションを作成します。 → △（惜しいが不正解）
関係者へ通知できる点は要件の一部を満たします。しかし、両者へ同時にメールを送るだけでは「マネージャーの承認後に財務へ進む」という順番を強制できません。承認・却下の記録、担当者ごとの作業項目、進捗管理も不足します。 この選択肢が適するのは、判断をSalesforceで管理せず、単に関係者へ情報共有したい場合です。
D. 特定の手順を含む承認プロセスを作成します。 → ⭕ 正解
承認プロセスに複数のステップを設定し、最初のステップを営業マネージャー、次のステップを財務担当に割り当てます。必要であれば追加の承認ステップや複数承認者を設定し、商談ごとの最大承認者数にも対応できます。 前のステップが完了してから次のステップを開始できるため、設問で要求される順序を強制できます。
管理者としての対処手順
Flow Approval Processを使用する場合
- ［設定］から［フロー］を開き、新しい承認プロセスを作成する
- 対象を商談にし、一定額を超え、成立前の確認が必要なレコードを開始条件に設定する
- 最初の承認ステップを作成し、営業担当のマネージャーを承認者に指定する
- 2番目の承認ステップを作成し、1番目のステップ完了後に開始するよう設定する
- 2番目の承認者を財務担当者に指定する
- 必要な場合は3番目の承認ステップ、またはステップ内の追加承認者を設定する
- 最終承認時に商談を成立状態へ進める更新処理を設定する
- 却下時は商談を営業担当へ戻し、理由を確認できるようにする
- テストユーザーで、承認順序・通知・履歴・却下経路を検証する
Classic Approval Processを使用する場合
- ［設定］→［承認プロセス］で対象オブジェクトに［商談］を選ぶ
- 進入条件に金額と商談フェーズの条件を設定する
- 承認ステップ1を営業マネージャーへ割り当てる
- 承認ステップ2を財務担当へ割り当てる
- 必要な追加ステップと承認者を設定する
- 最終承認・却下アクション、承認履歴関連リスト、申請方法を設定する
- 有効化して一連の承認経路をテストする
| 要件 | 必要な仕組み |
|---|---|
| マネージャーの後に財務が承認 | 順番に開始する複数の承認ステップ |
| 最大3人が関与 | 追加ステップまたは複数承認者の設定 |
| 判断履歴を残す | 承認作業項目と承認履歴 |
| 承認前に成立扱いにしない | 最終承認後の項目更新または後続処理 |
あわせて覚えておきたいポイント
- 順番に審査する、承認・却下を記録する、前の承認後に次へ進むという要件は承認プロセスの典型です。
- 画面フローやクイックアクションは、入力・通知の補助には使えますが、承認プロセスの代替ではありません。
- 現在はFlow Approval Processesがモダンな選択肢として提供されています。Classic Approval Processesも引き続き利用できます。試験では、選択肢が単に「承認プロセス」と書かれている場合、承認ステップで人の判断を順序制御する機能を指します。
- 最終承認前に商談を成立フェーズへ変更できないようにする方法は、組織の設計に応じて承認プロセスの更新処理や検証ルールと組み合わせます。
出典（Salesforce公式）
- Approval Steps — 前のステップが完了したときに次の承認ステップを開始できること、および承認者が非同期に判断することの根拠
- Add an Approval Step to a Classic Approval Process — 承認ステップが承認の連鎖、対象レコード、承認者を定義することの根拠
- Identify Assigned Approvers for an Approval Step in a Classic Approval Process — 各承認ステップの承認者を指定できること、およびFlow Approval Processesがモダンな代替として案内されていることの根拠