ServiceNowのUI PolicyとData Policyの違い｜画面制御とデータ制御の使い分け

ServiceNowでフォームの入力制御を設定するとき、UI Policy と Data Policy の違いで迷うことがあります。どちらも「必須にする」「読み取り専用にする」といった制御ができるため、最初は同じ機能のように見えます。

結論から言うと、UI Policyは画面上の見え方や入力しやすさを制御するもので、Data Policyはデータ保存時のルールを制御するものです。UI Policyはフォーム利用者の操作を助けるため、Data Policyは画面以外の登録経路も含めてデータ品質を守るために使います。

フォーム制御・インスタンス設定の理解をCSA模試で確認する
フォーム、リスト、設定、データ入力制御の判断問題を確認できます。

UI PolicyとData Policyの違いは「画面」か「保存ルール」か

UI PolicyとData Policyは、どちらもフィールド制御に関係します。ただし、どこで効くルールなのかが違います。

UI Policyは利用者の画面操作を助ける

UI Policyは、フォーム上で条件に応じてフィールドを表示したり、必須にしたり、読み取り専用にしたりするために使います。たとえば、優先度が高いときだけ理由欄を必須にする、特定の分類を選んだときだけ追加項目を表示するといった使い方です。

UI Policyの強みは、利用者がフォームを入力するときに、その場で必要な項目だけを見せられることです。フォームが長くなりすぎると入力ミスが増えるため、条件によって項目を整理できるUI Policyは実務でよく使われます。

ただし、UI Policyは主に画面上の制御です。画面で非表示にしたからといって、データベース上で絶対に値を入れられないという意味ではありません。権限や保存時のルールまで守りたい場合は、ACLやData Policyとの役割分担を考えます。

Data Policyは登録されるデータの品質を守る

Data Policyは、データが保存されるときのルールを制御するために使います。フォーム画面だけでなく、インポート、API、外部連携など、画面以外の入口からデータが作られる場合も意識する必要があります。

たとえば、「この条件では必ず理由を入れる」「この状態では特定フィールドを変更させない」といったルールを、画面操作だけに依存させたくない場合はData Policyを検討します。実務では、データ品質を守る最後の関門として考えると理解しやすいです。

Data PolicyのUse as UI Policy on clientを選ぶと、クライアント側のUI Policyエンジンでも条件に応じた必須・読み取り専用を反映できます。この選択を外しても、定義されたData PolicyのUI送信時のサーバー側検査まで無効になるわけではありません。入力中の見た目の変化と、保存時の検査を分けて理解します。仕様の確認先：Data policy。

API、Import Set、Flowから作られるデータも考える

ServiceNowのレコードは、利用者がフォームで入力するだけではありません。Import Set、REST API、Flow Designer、外部連携、スクリプトなど、複数の入口から作成・更新されます。

そのため、「フォームでは必須にしているから大丈夫」と考えると、画面以外の入口で空の値が入る可能性があります。データ品質はUI Policyだけに任せず、保存時のData Policyと、アクセス権のACLを分けて設計します。

Australiaの公式仕様では、Data Policyは既定でGlideRecord操作（Scripted REST API内を含む）とREST Table APIにも適用されます。一方、Import Setへの適用はApply to import sets、SOAPの対象レコードへの適用はApply to SOAPで確認します。後者はScripted SOAPには適用されず、RESTの適用にも影響しません。「SOAPをオフにすればRESTでもルールが外れる」という理解は誤りです。仕様の確認先：Data policy、Data policy fields。

実務ではどう選ぶべきか

迷ったときは、次の順で考えると判断しやすくなります。

1. 制御したいのは画面の見え方か、保存されるデータか
2. フォーム以外の入口からもレコードが作られるか
3. 保存時に必ず守りたいルールか
4. 利用者に入力中からわかりやすく見せたいか
5. 権限そのものを制御する話ではないか

フォーム上で利用者を迷わせないための制御ならUI Policyが自然です。対象の登録経路で保存時にも守りたい必須条件ならData Policyを検討し、その経路への適用設定を確認します。権限そのものを制御したい場合は、ACLとRoleの違いもあわせて確認してください。

UI Policy、Data Policy、Client Scriptを混同しない

UI PolicyとData Policyに加えて、Client Scriptもフォーム制御で出てきます。Client Scriptは、クライアント側でより柔軟な処理をスクリプトで書きたい場合に使います。

ただし、単純な必須、表示、読み取り専用の制御まで何でもClient Scriptで書くと、保守が難しくなります。まずUI PolicyやData Policyで実現できるかを確認し、それでも足りない場合にClient Scriptを使う、という順番のほうが管理しやすくなります。

よくある失敗例

• UI Policyだけで必須制御を完結させる: APIやImport Setから空値が入る可能性を見落とします。
• Data Policyで画面体験まで解決しようとする: 保存時エラーだけでは利用者が入力中に気づきにくくなります。
• Client Scriptで何でも書く: 単純な表示・必須制御までスクリプト化すると、後から読む人が意図を追いにくくなります。
• ACLとの役割を混同する: 必須制御とアクセス制御は別です。見せない・編集させない要件はACLも確認します。

CSA/CADではどう問われるか

CSAでは、UI Policyをフォーム上の制御、Data Policyをデータ保存時の制御として見分ける問題が出やすいです。問題文に「フォーム上で表示する」「入力中に必須にする」とあればUI Policyが候補になります。

CADでは、より実装寄りに、画面以外の登録経路、Client Scriptとの使い分け、ACLとの違いを問われることがあります。どこで効くルールなのかを意識すると選びやすくなります。

FAQ

まとめ

UI PolicyとData Policyは、どちらもフィールド制御に関わります。しかし、UI Policyは画面操作をわかりやすくするため、Data Policyは保存されるデータの品質を守るために使います。

実務で迷ったら、「これは利用者に見せる画面の話か、それともどの入口から登録されても守るべきデータルールか」を確認してください。この判断軸を持つと、フォーム設計のミスを減らせます。