高度な入力規則で入力チェックを強化！

認定SalesCloudコンサルタント

2019.06.29

より高度な入力規則が問われる

入力規則自体は認定アドミニストレーターでもテスト範囲内ではありましたが、ごくごく基本的で簡易的な内容でしか問われませんでした。

Sales Cloudコンサルタントではより高度な入力規則のチェック方法が問われ、さらにシナリオに応じて出題されるので、様々なケースに対して条件を引き出せるかが重要となってきます。

ここからは、ちょっと高度な入力規則の使用例です。
以下に挙げるものはいずれも試験の出題ポイントになるので、覚えておきましょう。

ログインユーザについての情報を入力規則の条件に加えることができます。

$Userを使用することで、ログインユーザの情報を参照することができます。

例）ログインユーザが所有者と一致しない場合はエラー

ログインユーザだけでなく、自身が属するプロファイルについても入力規則の条件に加えることができます。

プロファイルは権限の詰め合わせセットなので、役割に応じてこの人はOK、この人はダメと使い分けることが可能です。
$Profileを使用することで、ログインユーザの情報を参照することができます。

プロファイル名でチェックする時はName項目を使用します。
プロファイルにはDeveloperName的な論理名はないので、表示名を変更したらこちらも変更しないといけません。

例）プロファイル「システム管理者」以外はエラー

レコードタイプによって条件を使い分けることもできます。

レコードタイプでチェックする場合は、Name項目でなく、論理名であるDeveloperNameを使用するといいでしょう。
Name項目はラベル名にあたるので文言変更があった場合に影響がでてしまいます。

例）レコードタイプが「TypeA」だった場合にエラー

レコードのトリガについても確認することができます。
新規作成時にはISNEW()関数がTRUEになるので、新規作成か否かによって条件を分けることができます。

例）新規作成時にある項目がブランクだったらエラー

新規作成のチェックが可能なら、変更時のチェックも可能です。
変更の場合は、全く関係がないところを変更されてもチェックされることを防ぐために、変更した項目を指定できます。
ISCHANGED(項目名)関数で項目が変更された時にTRUEになります。

例）Hoge項目が変更され、なおかつブランクだった場合にエラー

以上が少し高度な入力規則の使い方ですが、肝心の試験では複合ケースを要するシナリオとして出題されることが多いです。

例）商談オブジェクトで「Closed Won」フェーズの時にシステム管理者以外のユーザが金額を変更した場合

複合ケースに対応するためにも、以下切り口でどのようなチェック方法を使用するか覚えておけば、入力規則の問題は難なく解けるのではないかと思います。