Administrator 練習問題 Q229
Cloud Kicksでは、商談がクローズされると、更新商談を自動的に作成したいと考えています。この要件を満たすために、管理者はどの自動化ツールを使用すべきですか?1つ選択してください。
左の○で回答を選択。本文を押すと横線で除外でき、もう一度押すと戻せます。
1つ選択してください(0/1)
正答:B. フロービルダー
解説
前提知識
商談のクローズとは
商談(Opportunity)をクローズするときは、成立(Closed Won)または不成立(Closed Lost)など、組織で設定したクローズ済みフェーズを選びます。設問は単に「クローズ」としており、成立時だけか、不成立も含むのかを明記していません。通常、更新商談の作成条件は成立時と考えられますが、本文にない条件を追加せず、実装前に対象となるクローズフェーズを確認する必要があります。
フロービルダーとは
フロービルダーは、Salesforceのクリックベースの自動化ツールです。レコードの作成・更新・削除、分岐、ループ、画面表示などを、コードを書かずに組み立てられます。 本問で使うのはレコードトリガフローです。これは、対象レコードが作成・更新されたときに条件を評価して自動実行するフローです。Salesforce公式のTrailheadでも、商談がClosed Wonなどの条件を満たしたときに、[レコードを作成]要素で別レコードを作成する例が示されています。 レコードトリガフローでは次を指定します。
- 対象オブジェクト(例:商談)
- トリガするタイミング(作成時、更新時、作成または更新時など)
- 実行条件(例:フェーズが「成立」に変わった)
- 実行するアクション(例:レコードを作成)
自動化ツールの現在の位置づけ
新規のレコードベース自動化にはFlow Builderを使用します。Process Builderは2025年12月31日でサポートと更新が終了し、既存プロセスは引き続き実行できますが、新規自動化にはフローが推奨されています。ただし、この事実から本問で欠けている2つ目の選択肢を推定することはできません。
設問の状況を分解する
要件は次の2つです。
- 商談がクローズされたときに(=引き金はレコードの更新)
- 新しい商談レコードを自動作成する ここで決定的なのは2の「別の商談レコードを新規作成する」という動作です。選択肢を要件への直接性で比較すると、残るのはフロービルダーです。
- 承認プロセス → レコードを承認経路に載せる機能。Classic承認プロセスの標準アクションには任意レコード作成がなく、Flow承認プロセスで作成処理を行う場合もバックグラウンドステップから呼び出すフローが必要
- 商談共有ルール → レコードアクセスを追加する
- 検証ルール → 条件に合わない値の保存を拒否する
- フロービルダー → レコードトリガーと[レコードを作成]要素で要件を直接実装できる
選択肢の検討
A. 承認プロセス → ✕
Classic承認プロセスは、申請、承認/却下、レコードロック、項目更新、メールアラート、タスク、アウトバウンドメッセージなどを構成する機能で、任意の新規商談を直接作成する標準アクションはありません。 現在のFlow承認プロセスにはレコードトリガー型があり、バックグラウンドステップから自動起動フローを呼び出せます。そのフロー内で新規商談を作成することは技術的には可能です。しかしFlow承認プロセスには少なくとも1つの承認ステップが必要で、本問には承認者や承認条件がありません。したがって、Aは要件に対して不要な承認経路を追加し、レコード作成自体もBのFlow Builderに依存するため、独立した正答とはしません。 これが正解になるのは、「値引きが20%を超える商談はマネージャーの承認を必須にしたい」など、承認判断が要件に含まれる設問です。→ 承認プロセスとは何か:「上司の承認をもらう」を仕組み化する
B. フロービルダー → ⭕ 正解
レコードトリガフローを使えば、商談が指定したクローズフェーズへ移行したときに自動実行し、[レコードを作成]要素で更新商談を生成できます。取引先など、更新商談へ引き継ぐ値と、新しい完了予定日・初期フェーズなどを明示的に設定します。表示されている選択肢の中で、要件へ直接対応するのはBです。
C. 商談共有ルール → ✕
共有ルールは、組織の共有設定(OWD)で非公開になっているレコードを、特定のユーザー群に見せる(または編集させる)ための機能です。アクセス権を広げるだけで、レコードを作ったり値を変えたりは一切しません。自動化ツールではなく、セキュリティの機能です。
D. 検証ルール → ✕
検証ルールは、保存しようとしているレコードの内容が条件に合わないときにエラーを出して保存を止める機能です。「止める」だけで、何かを作ったり更新したりする力はありません。 これが正解になるのは、「成立にするときは契約日の入力を必須にしたい」のような入力チェックの設問です。
管理者としての対処手順
- [設定]→ クイック検索に「フロー」と入力 →[新規フロー]。
- [レコードトリガフロー]を選択し、オブジェクトに「商談」を指定する。
- トリガーに[レコードが更新されたとき]を選ぶ。
- 業務要件を確認し、成立時だけなら「フェーズ=Closed Won」、すべてのクローズ済みフェーズを対象にするなら該当する条件を設定する。更新時の実行方法は[条件要件を満たすように更新されたときのみ]を選ぶ。これにより、条件を満たした後の通常編集で更新商談が繰り返し作成されるのを防ぐ。
- 実行タイミングは[レコードの保存後]を選ぶ。別レコードを作成する場合は保存前ではできません。
- [レコードを作成]アクションを追加し、商談名・取引先・金額・完了予定日・フェーズなどをセットする。元の商談の値はトリガーレコード変数から参照できる。
- デバッグで動作を確認し、[有効化]する。
⚠️ [条件要件を満たすように更新されたときのみ]を使えば、クローズ後の通常編集では再実行されません。ただし、商談を再オープンして再度クローズした場合にも作成を一度だけにしたいなら、[更新商談作成済み]などの項目や作成済み更新商談の検索を追加して冪等性を確保します。作成される更新商談の初期フェーズがフローの開始条件を満たさないことも確認します。
あわせて覚えておきたいポイント
自動化系の問題は、**「その機能に何ができて、何ができないか」**を表で押さえると一気に楽になります。
| 機能 | レコード作成 | 項目更新 | 主な用途 |
|---|---|---|---|
| フロービルダー | できる | できる | レコードベースの自動化全般 |
| Classic承認プロセス | 任意レコードを直接作成する標準アクションはない | 承認アクションとして可能 | 人による承認の仕組み化 |
| Flow承認プロセス | バックグラウンドステップから呼ぶ自動起動フローで可能 | バックグラウンドステップから呼ぶフローで可能 | 承認ステップを含む複雑な承認経路 |
| 検証ルール | できない | できない | 条件に合わない保存を止める |
| 共有ルール | できない | できない | アクセス権を広げる |
| 割り当てルール | できない | 所有者のみ | 新規レコードの振り分け |
| 数式項目 | できない | 表示のみ(保存しない) | 計算結果の表示 |
「レコードの変更を契機に、別レコードを自動作成する」という要件では、まずレコードトリガフローと[レコードを作成]要素を検討します。承認、共有、入力チェックは別の目的を持つ機能です。
出典(Salesforce公式)
- Build a Record-Triggered Flow(Trailhead) — 商談がClosed Wonなどの開始条件を満たしたときだけレコードトリガフローを実行し、[レコードを作成]要素で別レコードを作成する構成を裏付ける。
- Create a Record from a Process(Salesforce Help) — Process Builderのサポートと更新が2025年12月31日に終了し、新規自動化にはFlow Builderが推奨されることを裏付ける。
- Create Approval Processes(Salesforce Help) — Classic承認プロセスの標準アクションがタスク、メールアラート、項目更新、アウトバウンドメッセージであることを裏付ける。
- Create a Flow Approval Process from Scratch(Salesforce Help) — レコードトリガー型のFlow承認プロセスを作成できること、各Flow承認プロセスに少なくとも1つの承認ステップが必要であることを裏付ける。
- Steps in Flow Approval Processes(Salesforce Help) — バックグラウンドステップが自動起動フローを実行できることを裏付ける。
- Creating a Salesforce Record from a Flow(Salesforce Help) — Flowの[レコードを作成]要素でSalesforceレコードを新規作成できることを裏付ける。
- Validation Rules(Salesforce Help) — 入力規則が保存前にデータを検証し、条件違反時にエラーを表示する機能であることを裏付ける。
- Sharing and Record Access Features — 共有ルールが組織全体のデフォルト共有設定に対する例外としてアクセス権を拡張するための機能であること(自動化ツールではないことの根拠)
- Get Started with Validation Rules(Trailhead) — 検証ルールが、定義した条件を満たさないレコードの保存をエラーで阻止する仕組みであること