Administrator 練習問題 Q81

解説

前提知識

承認処理で必要な二つの判断

承認を自動化するとき、管理者は次の二つを分けて考えます。

1. いつ承認を開始するか
2. 誰に承認を割り当てるか 今回の要件では、商談の項目値を見て、30通りの条件から適切なチームリーダーを決定する必要があります。これは単純な一直線の承認ではなく、データに応じて経路と担当者を動的に変えるルーティングです。

Classic Approval Processとは

従来の承認プロセスです。オブジェクトごとにエントリ基準、承認ステップ、承認者、承認・却下時のアクションを設定します。 条件が少なく、承認経路がほぼ固定なら、Classic Approval Processで十分です。しかし公式は、Classic Approval Processについて、条件を使った処理には限定的な対応しかなく、より柔軟な代替としてFlow Approval Processesを案内しています。

Flow Approval Processesとは

Flow Builderで作成する現在の承認自動化機能です。ステージ、承認ステップ、バックグラウンドステップ、決定要素を組み合わせて、条件に応じた複雑な承認経路を構成できます。 公式はFlow Approval Processesについて、次のように説明しています。

“It supports dynamic routing based on data and business rules.” つまり、レコードの値と業務ルールに基づいて承認先を動的に振り分けることができます。本問の「30通りの条件から担当者を決める」は、この機能の得意分野です。 また、公式はステージやステップの開始条件が10件を超える場合について、次のように案内しています。 “Use an evaluation flow to create more complex criteria.” 30通りの条件を、一つずつClassic Approval Processとして複製するのではなく、評価フローや決定要素で条件判定を集約する設計が適切です。 📘 承認プロセスの基本用語や、エントリ基準・承認ステップ・承認者の関係がまだモヤッとする方へ→ 承認プロセスとは何か：「上司の承認をもらう」を仕組み化する

設問の状況を分解する

1. 対象は商談である
2. 特定のチームリーダーによる検証、つまり承認が必要である
3. 承認先は固定ではない
4. 商談の複数項目を組み合わせた条件が30通りある
5. 条件に応じて適切な担当者へ自動的にルーティングする必要がある 本問の決定的な語は**「30通り」**です。 少数の固定条件ならClassic Approval Processでも構成できます。しかし、30通りごとに別の承認プロセスを作ると、通知、承認ステップ、却下処理などを変更するたびに多数の設定を修正する必要があります。条件の重複や評価順序の誤りも起きやすくなります。 したがって、条件判定をフローに集約し、データに応じて担当者を決められるCを選びます。

---

選択肢の検討

A. 適切なリーダーへ送信するメールテンプレートを表示するボタンを作成する → ✕

メールは通知手段であり、承認プロセスではありません。 この方法では、次の機能が不足します。

• 承認・却下の正式な記録
• 承認待ちレコードの管理
• 承認者への作業項目の割り当て
• 承認結果に応じた後続処理
• 30通りの条件による自動ルーティング 単に担当者へ連絡したい要件なら候補になりますが、正式な検証プロセスを作る本問には適しません。

B. 条件の組み合わせごとに、エントリ基準と承認ステップを含む承認プロセスを作成する → ✕

承認プロセスを使うという方向は合っていますが、条件の組み合わせごとに作成する点が不適切です。 30通りなら最大30本のプロセスが必要になり、次の問題が発生します。

• 評価順序の管理が複雑になる
• 同じ承認アクションや通知を多数の場所で保守することになる
• 条件を追加・変更したときに修正漏れが起きる
• どのプロセスが実行されたかを追跡しにくい Classic Approval Processは単純で固定的な承認には有効ですが、本問のような動的ルーティングには、公式が現代的な代替として案内するFlow Approval Processesの方が適しています。

C. レコードトリガーのフローオーケストレーションを作成する → ⭕ 正解

商談の作成または更新を起点にし、商談の項目値を評価して適切な承認経路と担当者を決定できます。 現在のFlow Approval Processesでは、次の構成が可能です。

• レコード変更を開始条件にする
• 決定要素で条件を分岐する
• 複雑な条件を評価フローにまとめる
• 承認ステップをユーザー、グループ、キューへ割り当てる
• 承認前後の自動処理をバックグラウンドステップとして実行する
• 実行履歴や滞留箇所を監視する 30通りの条件を一つの自動化の中で管理できるため、要件と保守性の両方を満たします。

D. 画面フローで営業担当者に条件を入力させ、適切なリーダーへ送信する → ✕

すでに商談レコードに判定材料があるなら、営業担当者へ同じ情報を再入力させる必要はありません。 人の入力に依存すると、入力ミスや選択間違いが発生します。また、通常の画面フローだけでは、承認作業項目、承認履歴、承認・却下の一連の管理を自動的には提供しません。 ユーザーへの追加質問が必要な申請フォームなら画面フローが適しますが、既存データから自動判定できる本問では不正解です。

---

管理者としての対処手順

1. ［設定］から［フロー］または［承認］アプリを開く
2. ［新規自動化］でレコードトリガーフロー承認プロセスを選択する
3. 対象オブジェクトを商談にし、承認判定を開始する作成・更新条件を設定する
4. 30通りの条件を整理し、［決定］要素または評価フローで判定する
5. 条件から承認担当者を決定する。担当者の対応表が頻繁に変わる場合は、ユーザー参照項目やカスタムメタデータ型に対応関係を保持する
6. 承認ステップを作成し、判定結果に応じてユーザー、グループ、またはキューへ割り当てる
7. 必要に応じて、承認前の通知や項目更新をバックグラウンドステップに追加する
8. 条件30通りについて、該当する経路、該当しない経路、境界値をテストする
9. 有効化後は実行履歴を確認し、誤ったルーティングや滞留がないか監視する

条件の持ち方	向いている状況
決定要素へ直接記述	条件が安定しており、変更頻度が低い
評価フロー	条件が多く、判定ロジックを分離してテストしたい
カスタムメタデータ型	条件と担当者の対応表を管理者がデータとして変更したい
商談のユーザー参照項目	他の自動化で承認担当者を事前計算しておきたい

---

あわせて覚えておきたいポイント

• 条件の数が増えたら、設定の本数を増やすのではなく、判定ロジックを集約すると考えます。
• Classic Approval Processが誤った機能というわけではありません。固定的で単純な承認では現在も利用できます。
• 現在の公式ドキュメントは、柔軟な動的ルーティング、レコード変更による起動、詳細なログが必要な場合にFlow Approval Processesを案内しています。
• 承認先をユーザー名で大量にハードコードすると、人事異動のたびにフローを編集することになります。ユーザー参照項目、グループ、キュー、カスタムメタデータ型を使って変更箇所を分離します。
• 30通りすべてについて正常系だけでなく、複数条件に同時一致する場合と、どの条件にも一致しない場合もテストします。

---

出典（Salesforce公式）

• Classic Approval Processes — 「Flow Approval ProcessesはClassic Approval Processesの現代的な代替であり、データと業務ルールに基づく動的ルーティングをサポートする」
• Flow Approval Processes — 「フロー承認プロセスはステージ、ステップ、決定で複雑な承認シーケンスを構成でき、レコードトリガー型を選択できる」
• Automate Your Approvals with Flow Approval Processes — 「ステージには承認ステップまたはバックグラウンドステップを配置でき、決定要素で条件に応じた実行経路を決められる」
• Flows in Flow Approval Processes — 「ステージやステップの開始制御に10件を超える要件がある場合は、複雑な条件を評価フローで作成する」
• Flow Approval Process Types — 「フロー承認プロセスの種類によって開始方法が決まり、レコードの作成・更新を開始条件にできる」

Salesforce公式ドキュメント↗