Administrator 練習問題 Q134

解説

前提知識

入力規則（検証ルール）とは

「この条件に当てはまったらエラーにする」という式を書く仕組みです。レコードが保存されるたびに評価され、式の結果が true になるとエラーメッセージを表示して保存を止めます。画面入力・API・データローダ・フローなど、どの経路からの保存でも効きます。 最大の強みは、条件付きで必須にできることです。「フェーズが商談中のときは空欄でよいが、失注にするときは理由が必要」といった要件は入力規則で表現できます。現在はレコードトリガーフローの［カスタムエラー］でも保存を止められますが、提示された選択肢の中では入力規則が適切です。

項目定義の［必須］チェックボックス（普遍的に必須の項目）

カスタム項目の設定画面にある［必須］チェックボックスです。オンにすると、すべてのレコードタイプ・すべてのページレイアウト・API経由の登録まで、例外なく必須になります。 ただし制約があります。公式ヘルプは「普遍的に必須の項目はすべてのレコードタイプで必須になる」「標準項目は普遍的に必須にできない」と明記しています。さらに重要なのは、項目の種別によってはこのチェックボックス自体が存在しないことです。

リッチテキスト形式のテキストエリア項目

太字や箇条書き、画像を含められる書式付きのテキスト項目です。内部的にはHTMLとして保存されます。この項目種別には、項目定義の［必須］チェックボックスがありません。

💡 ここがまだモヤッとする方へ。必須化の4つの手段と、どれがどこまで効くのかを整理した記事があります → Salesforceで項目を入力必須にする方法を整理する

ワークフロールール

条件を満たしたときに、項目更新・メール送信・ToDo作成・アウトバウンドメッセージを実行する旧世代の自動化機能です。エラーを出して保存を止める機能はありません。加えて、Workflow Rules のサポートと更新は2025年12月31日に終了しています。既存ルールは引き続き実行・編集できますが、SalesforceはFlow Builderへの移行を推奨しています。

設問の状況を分解する

1. 損失理由を記録したい
2. 記録先はリッチテキスト項目
3. 記録が必要なタイミングは商談がクローズされたとき 2つの制約が重なっている点がこの設問の核心です。

• 項目種別の制約：リッチテキスト項目には［必須］チェックボックスがない
• 条件の制約：常に必須ではなく、クローズ時だけ必須にしたい どちらか一方だけでも入力規則が有力ですが、両方が重なることで、提示された選択肢の中では入力規則だけが要件を満たします。 初学者が誤解しやすいのは、「必須にしたい＝［必須］チェックボックスを入れる」と反射的に考えてしまう点です。Salesforceでは、項目の種別によって使える必須化の手段が変わることを押さえておく必要があります。

---

選択肢の検討

A. ページレイアウトの損失理由フィールドの横にある要件チェックボックスを選択します。 → ✕

ページレイアウトの［必須］は、そのページレイアウトの画面から入力するときだけ効きます。データローダやAPI経由なら空欄で通ってしまいます。 さらに致命的なのは、条件を指定できないことです。ページレイアウトで必須にすると、フェーズが「提案中」でも「交渉中」でも、常に損失理由の入力を求められます。まだ失注していない商談で損失理由を書かせるのは明らかに不自然です。要件は「クローズされたとき」なので不適切です。

B. ステージがクローズで失われ、損失理由が空白の場合にエラーを表示する検証ルールを作成します。 → ⭕ 正解

「フェーズが失注（Closed Lost）である」かつ「損失理由が空欄である」という条件を式で書き、両方を満たしたときにエラーを出します。リッチテキスト形式のテキストエリアは一部の数式関数に制約があるため、Salesforce公式は空欄判定に LEN(損失理由__c) = 0 を案内しています。これにより次の3つがすべて満たされます。

• リッチテキスト項目でも必須化できる（項目種別の制約を回避できる）
• クローズ時だけ必須にできる（条件付き必須）
• 画面・API・データローダ、どの経路でも止められる 設問の2つの制約に同時に対応できる唯一の選択肢です。

C. オブジェクトマネージャの損失理由項目で必須のチェックボックスをオンにします。 → ✕（惜しいが不正解）

最も引っかかりやすい選択肢です。理由は2つあります。

1. そもそもチェックボックスが存在しない。リッチテキスト形式のテキストエリア項目は、項目定義で必須にできません
2. 仮にできたとしても条件を付けられない。普遍的に必須の項目は全レコードタイプ・全フェーズで必須になるため、商談を新規作成した瞬間から損失理由の入力を強制されてしまいます これが正解になるのは、「すべてのレコードで、作成時点から例外なく必要」かつ「テキストや数値など、必須化に対応した項目種別」の場合です。

D. 損失理由が空白の場合にエラーを表示するようにワークフロールールを構成します → ✕

選択肢の文章自体が成立していません。ワークフロールールにはエラーを表示して保存を止めるアクションが存在しないためです。できるのは、項目更新・メール送信・ToDo作成・アウトバウンドメッセージの4つだけです。 また、Workflow Rules のサポートと更新は2025年12月31日に終了しており、現在の推奨はFlow Builderです。本問のような単純な条件付き入力チェックでは、**「エラーを出して保存を止めるなら入力規則」**と判断します。

---

管理者としての対処手順

1. ［設定］→［オブジェクトマネージャ］→［商談］を開く
2. ［項目とリレーション］で、リッチテキスト形式の損失理由項目が存在することを確認する（なければ作成する）
3. ［入力規則］→［新規］を選ぶ
4. 入力規則名と、エラーが出たときに表示する説明文を入力する
5. エラー条件の式に、次の考え方で条件を組み立てる
   • 商談のフェーズが失注（Closed Lost）である
   • かつ、LEN(損失理由__c) = 0 である（リッチテキスト項目の空欄判定）
6. エラーメッセージを、担当者が何をすべきか分かる文言にする（例：失注として保存するには、損失理由の入力が必要です）
7. エラーメッセージの表示場所を、損失理由項目の横に設定する
8. サンドボックスで、フェーズを失注に変更したときだけエラーが出ることを確認する

⚠️ リッチテキスト項目では一部の数式関数が使えません。公式は空欄判定に LEN() を案内していますが、画像だけを挿入した場合などは文字数判定で期待どおりにならないことがあります。実装後は、空欄・空白・書式だけ・画像だけのケースをサンドボックスで確認してください。

---

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

• 必須化の使い分けは「効かせたい範囲」で決まります。無条件・全経路なら項目定義の必須、条件付きなら入力規則、画面だけでよいならページレイアウト。
• 標準項目は普遍的に必須にできません。標準項目を必須にしたい場合も、入力規則かページレイアウトを使います。
• 商談には「損失理由」に相当する標準的な運用として、フェーズと連動した必須化がよく求められます。試験では「クローズ時だけ」「特定のレコードタイプのときだけ」といった条件語が入っていれば、ほぼ入力規則が正解です。
• Workflow Rules と Process Builder は旧世代の自動化です。Workflow Rules のサポートと更新は2025年12月31日に終了し、SalesforceはFlow Builderへの移行を推奨しています。ただし、旧機能であることだけを理由に誤答とせず、選択肢の機能が要件を実現できるかで判定します。

---

出典（Salesforce公式）

• Considerations for Universally Required Fields — 「普遍的に必須の項目はすべてのレコードタイプで必須になる」「標準項目は普遍的に必須にできない」（条件付き必須にできないことの根拠）
• Unable to create a formula field that has a rich text area field — リッチテキスト項目は入力規則で利用できるが一部関数に制約があり、空欄判定には LEN(項目) = 0 を使用すること
• Validation Rules — 入力規則が保存時に評価され、条件に違反するとエラーメッセージを表示してレコードを保存しないこと
• Workflow Rules — Workflow Rules のサポートと更新が2025年12月31日に終了し、既存ルールは継続するもののFlow Builderへの移行が推奨されていること
• Define Validation Rules — 入力規則の作成手順と、条件を満たしたときにエラーメッセージを表示して保存を止める挙動
• Require Field Input to Ensure Data Quality — 項目の入力を必須にする手段の位置づけ

Salesforce公式ドキュメント↗