top of page

【応用編】Salesforce入力規則の秘訣と実践ガイド

更新日:9 時間前





  目次



  はじめに


前回の記事では入力規則で組み立てる基本的な数式の例についてご紹介をしました。

今回の記事ではもっと複雑な要件に対応できるよう、前回よりも難しい数式を使用した入力規則の事例を2つご紹介していきます。



  利用シーン①商談に秘匿チェックをつけたい



ありがちな利用シーン①:

営業が商談データを登録する際に、重大な商談の場合は秘匿チェックをつけたいが、営業以外の社員は秘匿チェックをつけることを許可しない。


これをSalesforceの仕様に変換するとこうなります。



■要件

A社では、重大な商談の場合、商談のカスタムチェックボックス項目[秘匿チェック]を有効にする運用になっています。この秘匿チェックは営業部ロールに所属するユーザーのみ有効にすることができ、他のロールに所属するユーザーが有効にした場合はデータ保存をブロックしたいです。


こちらの要件を満たす数式は下記の通りです。

※あくまで一例です。


【数式例】

AND( 項目のAPI参照名 , $UserRole.Name <> "営業部")


上記数式におけるポイントは2つです。


ポイント1:チェックボックス項目がTrueの時を判定したい場合、「=True」を省略できる!


今回チェックボックス項目が有効=Trueだった時、という条件をまず数式で組み立てる必要があります。チェックボックス項目が有効になっているとき、ついつい「項目のAPI参照名

=True」と記述してしまいそうですが、実は省略可能です。一方Falseの場合は、きちんと「項目のAPI参照名 = False」と記述する必要があります。

Trueの場合の条件式を組み立てたいのであれば、省略して数式をなるべくコンパクトにしましょう!


ポイント2:入力規則の数式では項目以外の情報も使用できる!


前回の記事では、項目のAPI参照名と関数を用いた数式をご紹介しました。

しかし今回の数式を見てみると、「$UserRole.Name」という見慣れない差し込み項目があります。実はこちらは「現在のユーザーのロール名」を指しています。

「現在の」というのが少し分かりにくいかと思いますが、言い換えると「今保存を実行した」であり、 「$UserRole.Name」は「今保存を実行したユーザーのロール名」ということになります。

$UserRole.Name <> "営業部"」という数式を組み立てることで「今保存を実行したユーザーのロール名が営業部ロールではないとき」という条件を作成することができます。

$UserRoleの他にも$User.Departmentなどを使用でき、オブジェクト項目のAPI参照名以外を使用して入力規則のエラー数式を組み立てることが可能ということが大きなポイントです。


API参照名は一つ一つ手入力することができますが、一文字でも誤って入力してしまうと正しく動作しません。[項目の挿入]ボタンをクリックすると、数式で利用できる項目が一覧になって表示されますので、こちらを使用することをおすすめします。





ポイント1とポイント2を踏まえると、「AND( 項目のAPI参照名 , $UserRole.Name <> "営業部")」こちらの数式は、秘匿チェックが有効になっている且つ保存を実行したユーザが営業部ロールではない場合にTrueを返すため、要件通り入力規則が動作し、保存がブロックされるということになります。




複雑な入力規則もプロにお任せ!

テラスカイテクノロジーズのエンジニア派遣の資料ダウンロードはこちら→https://bit.ly/3C3OsEi



  利用シーン②フリガナを半角カタカナで入力させたい


ありがちな利用シーン②:

取引先責任者のデータを登録する際、フリガナは必ず半角カタカナで入力させたい。


■要件

A社では、取引先責任者のフリガナを入力する名前カナというカスタム項目を作成しました。取引先責任者データを作成・編集する際、半角カタカナ以外で入力された場合はデータ保存をブロックしたいです。


こちらの要件を満たす数式は下記の通りです。※あくまで一例です。


【数式例】

NOT (REGEX (名前カナのAPI参照名, "^[ァ-ー]+$" ))


上記数式は、項目に入力された文字がルールに基づいているかについて判定をするREGEX関数を用いて組み立てています。今回の要件におけるルールとは「全角カタカナで入力」することでした。少し数式を分解して見ていきましょう。


 REGEX (名前カナのAPI参照名, "^[ァ-ー]+$" )


上記数式は項目に入力されている値がルール「全角カタカナで入力」に従っているかを判定し、従っている場合はTrue、そうでない場合はFalseを返します。


 NOT (REGEX (名前カナのAPI参照名, "^[ァ-ー]+$" ))


その後NOT関数を使用して「ルールに従っていること=True」を否定しているので、結果的に全角カタカナ以外で入力された場合はエラー判定となるロジックです。






REGEX関数の使い方については下記ヘルプを参照ください。


REGEX関数の中身に記述した、正規表現と呼ばれる部分 "^[ァ-ー]+$" のメタ文字について、少し解説します。


----------------------------------------------------------


^:先頭文字から

[ァ-ー]:全角カタカナが

+:1文字以上

$:最後まで連続している


----------------------------------------------------------



今回のように全角カタカナ以外が入力された場合エラーとする入力規則以外にも、電話番号が[××-××××-××××]、郵便番号が[△△△-△△△△]の形式以外が入力された場合エラーとする入力規則など、REGEX関数を用いることで要件に合わせた入力規則を設定できます。

より詳しい正規表現の組み立て方については本筋と逸れるため解説しませんが、このようにREGEX関数を活用することで組織内のデータの整合性を保ち、データ品質の向上に繋がります。





  最後に


2つの記事を通して入力規則の数式例について紹介・解説をしていきました。

1つ目の記事にも記載しました通り、要件が複雑な場合は下記を実行してみましょう。


①要件を一つひとつかみ砕いて、分解していく

②細かく数式を組み立てていく

③組み立てた、いくつかの数式を合体させる


こちらの記事で、入力規則や数式についての理解が深まれば幸いです。




複雑な入力規則もプロにお任せ!

テラスカイテクノロジーズのエンジニア派遣の資料ダウンロードはこちら→https://bit.ly/3C3OsEi

Comments


bottom of page