Skip to main content

ベストプラクティスを実践する

学習の目的

この単元を完了すると、次のことができるようになります。

  • ユーザーフレンドリーな入力規則を設計する。
  • 既存のデータを検討する入力規則を作成する。
メモ

メモ

日本語で受講されている方へ
Challenge は日本語の Trailhead Playground で開始し、かっこ内の翻訳を参照しながら進めていってください。Challenge での評価は英語データを対象に行われるため、英語の値のみをコピーして貼り付けるようにしてください。日本語の組織で Challenge が不合格だった場合は、(1) この手順に従って [Locale (地域)] を [United States (米国)] に切り替え、(2) [Language (言語)] を [English (英語)] に切り替えてから、(3) [Check Challenge (Challenge を確認)] ボタンをクリックしてみることをお勧めします。

翻訳版 Trailhead を活用する方法の詳細は、自分の言語の Trailhead バッジを参照してください。

検証をユーザーフレンドリーにする

入力規則のエラーメッセージは、ユーザーが検証をクリアして先に進むための道標と考えることができます。以下は、[Amount (金額)] 項目の効果的なエラーメッセージの一例です。

フェーズが「評価」以降の場合は、金額を入力する必要があります。[OPP003]

このエラーメッセージが効果的な理由と、エラーメッセージを同様に効果的にするにはどうすればよいのかを詳しく見ていきます。 

エラーメッセージを明確にする。

エラーメッセージは端的で、規則がトリガーされた理由とエラーを修正するためにすべきことをユーザーに的確に伝える必要があります。上記の例では、どのフェーズで金額が必要になるのかを正確に理解できます。金額を入力する準備ができていない場合は、フェーズを調整できます。

一意のエラーコードを含める。

上記のエラーメッセージのように、一意のエラーコードを含めることをお勧めします。ユーザーから問い合わせがあった場合に、このエラーコードがわかれば入力規則を特定しやすくなります。オブジェクトを識別できる命名規則に従うようにします。たとえば、商談の入力規則はすべて先頭を「OPP」にし、その後に個々の商談の入力規則を識別する連番を続けることが考えられます。積み上げ集計や自動化で関連レコードが更新された場合に入力規則が実行されることがあるため、こうした命名が特に役立ちます。設定で関係のないオブジェクトを確認していたことに気付いたときほど苛立つことはありません!

エラーを表示する場所を慎重に選択する。

可能な限り、エラーメッセージは項目に表示します。上記の例のように、エラーメッセージを項目に表示すると、エラーメッセージ内にリンクが表示され、ユーザーがそのリンクから問題のある項目に直接移動して修正することができます。

一度に 1 つのシナリオに絞る。

商談が「評価」フェーズに設定された時点で、「金額」と「次のステップ」の両方に入力する必要がある場合はどうすればよいのでしょうか? 1 つの入力規則を使用して、数式の両方の項目をチェックしたくなるかもしれません。この場合、エラーメッセージから、いずれかの項目に値が必要なのか、両方の項目に値が必要なのかがユーザーに伝わらないため、ユーザーが混乱する可能性があります。また、注意が必要な両方の項目にエラーメッセージを表示することはできません。この 2 つの要件を別々の入力規則に分ければ、数式が簡潔になり、ユーザーへのフィードバックがわかりやすくなります。

レコードの変更を適切に処理する

ビジネス要件は時間の経過とともに変化するため、それに応じて新しい入力規則の追加が必要になる場合があります。前の単元で使用した例を考えてみましょう。「取引先番号は 8 桁でなければならない」という要件がありました。既存のデータの取引先番号がこの要件を満たしていない場合はどうなるでしょうか? ユーザーがこのいずれかのレコードを編集するときに、取引先番号を編集しなければ、8 桁の取引先番号が必要というエラーが表示されます。

この点が問題になる可能性があるのは特に、ユーザーに取引先番号項目を編集する権限がない場合です! こうした問題を回避するには、入力規則の数式に、レコードが新規作成された場合または取引先番号が変更された場合を検出する関数を追加します。

以下は、特定のシナリオに入力規則を適用する場合に役立つ関数の数例です。

  • ISCHANGED(field_name) 特定の項目の値が変更されている場合に TRUE を返します。この関数を使用すると、規則の対象となる項目が変更されている場合にのみ、入力規則を選択的に実行できます。
  • ISNEW() レコードが作成されているときに TRUE を返します。通常は ISCHANGED を使用するときに ISNEW() も使用します。レコードが作成されているときは、項目が変更として検出されません。
  • PRIORVALUE(field_name) この便利な数式では前の値を確認できます。この 1 つの用途として、商談を「商談成立」から変更できないようにする場合が挙げられます。そのために、商談フェーズの前の値を確認することができます。前の値が「商談成立」で、フェーズが変更されている場合は、ユーザーにエラーを表示できます。

変更を検出する入力規則を作成する

続いて、変更を検出する入力規則を作成してみます。ここでは、新規商談、または完了予定日が変更された商談は、完了予定日が今日以降でなければならないという新しい入力規則を作成します。(この規則が既存のデータでどのように機能するか確認したい場合は、この入力規則を作成する前に、Playground に完了予定日が今日より前の商談があることを確認してください。)

  1. [設定] で [オブジェクトマネージャー] をクリックします。
  2. [Opportunity (商談)] をクリックします。
  3. 左サイドバーで、[Validation Rules (入力規則)] をクリックします。
  4. [新規] をクリックします。
  5. 入力規則に次のプロパティを入力します。
    1. Rule Name (ルール名): OPP001_Close_Date_After_Today
    2. Description (説明): The close date must be today or later for new opportunities or when the close date is changed. (新規商談、または完了予定日が変更された商談については、完了予定日が今日以降でなければなりません。)
    3. エラー条件数式:
AND(
  OR(
    ISNEW(),
    ISCHANGED(CloseDate)
  ),
  CloseDate<TODAY()
)

d. Error Message (エラーメッセージ): The close date must be today or later [OPP001] (完了予定日が今日以降でなければなりません [OPP001])

e. Error Location (エラー表示場所): Field (項目)、Close Date (完了予定日)

6. [保存] をクリックします。

さまざまなシナリオでこの入力規則がどのように機能するか試してみます。

  • 完了予定日が今日より前の新規商談は作成することができません。
  • 商談の完了予定日を昨日に更新することはできません。
  • 商談の完了予定日を今日に更新することはできます。
  • 完了予定日が過去の商談でほかの項目を更新することはできます。

次は、入力規則にスキップスイッチを追加する方法について説明します。

リソース

Salesforce ヘルプで Trailhead のフィードバックを共有してください。

Trailhead についての感想をお聞かせください。[Salesforce ヘルプ] サイトから新しいフィードバックフォームにいつでもアクセスできるようになりました。

詳細はこちら フィードバックの共有に進む