ServiceNowのClient ScriptとBusiness Ruleの違い｜クライアント側とサーバー側の使い分け

ServiceNowでスクリプトを学び始めると、Client Script と Business Rule の違いでつまずきやすくなります。どちらもJavaScriptを書けるため、「どちらに書いても同じではないか」と見えてしまうことがあります。

結論から言うと、Client Scriptはユーザーの画面上で動く処理で、Business Ruleはサーバー側でレコード操作に合わせて動く処理です。つまり、違いの中心は「JavaScriptかどうか」ではなく、どこで、いつ、何を制御するかです。

スクリプト・自動化の理解をCSA模試で確認する
Business Rule、Flow Designer、フォーム制御の使い分けを問題形式で確認できます。

Client ScriptとBusiness Ruleの違いは「画面側」か「サーバー側」か

Client ScriptとBusiness Ruleは、どちらもServiceNowの動きを変えるために使います。ただし、実行される場所と目的が違います。

Client Scriptはフォーム操作を助ける

Client Scriptは、ユーザーがフォームを開いたり、フィールドの値を変更したり、送信しようとしたりするタイミングで動くクライアント側のスクリプトです。フォーム上で値を自動入力する、警告を出す、項目の表示を切り替える、といった処理に向いています。

たとえば、カテゴリを選んだらサブカテゴリ候補を変える、入力値に応じて注意メッセージを出す、送信前に簡単なチェックをする、といった場面です。利用者が入力中に気づけるようにする処理はClient Scriptで考えやすいです。

ただし、Client Scriptはユーザーの画面操作に近い処理です。API、インポート、Flow、バックグラウンド処理など、画面を通らない登録経路では期待通りに効かないことがあります。絶対に守るべきデータルールをClient Scriptだけに任せるのは危険です。

// onChange Client Script の考え方
// 入力中のユーザーに注意を出す用途に向いています
function onChange(control, oldValue, newValue, isLoading) {
  if (isLoading || newValue === '') return;

  if (newValue === '1') {
    g_form.showFieldMsg('priority', 'High priority requires careful review.', 'info');
  }
}

Business Ruleはレコード操作に近いサーバー側処理

Business Ruleは、レコードがinsert、update、delete、queryされるタイミングに合わせてサーバー側で動くルールです。保存前に値を整える、保存後に関連レコードを更新する、特定条件でエラーにする、といった処理に向いています。

Business Ruleの強みは、画面操作以外の登録経路も含めて、サーバー側で一貫した処理を行えることです。利用者がフォームから更新した場合だけでなく、連携やインポートで更新される場合も考慮したい処理はBusiness Ruleの候補になります。

一方で、Business Ruleは影響範囲が広くなりやすいです。条件が広すぎると想定外の更新でも動きますし、同じレコードを再更新する設計では処理が連鎖することもあります。Flow Designerとの使い分けは、Business RuleとFlow Designerの違いでも整理しています。

// before Business Rule の考え方
// 画面以外の入口でも保存前に値を整えたい場合に検討します
if (current.short_description) {
  current.short_description = current.short_description.trim();
}

実務ではどう選ぶべきか

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

1. その処理はユーザーが入力中に気づくべきものか
2. フォーム画面以外の登録経路でも必ず効かせたいか
3. 保存前後のデータ整合性に関わるか
4. UI PolicyやData Policyで実現できないか
5. 同じ処理を画面側とサーバー側に二重実装していないか

画面操作をわかりやすくするならClient Script、保存されるデータの整合性を守るならBusiness Ruleが候補です。単純な必須や表示制御なら、まず UI PolicyとData Policyの違い を確認し、スクリプトが本当に必要かを考えると保守しやすくなります。

よくある失敗例

• Client Scriptで必須チェックを完結させる: APIやImport Setから登録された場合にチェックを通らない可能性があります。
• Business Ruleで画面メッセージ中心の処理を書く: 入力中に気づかせたい処理はClient ScriptやUI Policyのほうが自然です。
• 同じロジックを両方に書く: 画面側とサーバー側で判定条件がずれ、原因調査が難しくなります。
• GlideRecordをClient Scriptに直接書こうとする: クライアント側とサーバー側のAPIを混同しないようにします。

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

CSAでは、Client Scriptをクライアント側、Business Ruleをサーバー側の処理として見分ける問題が出やすいです。画面上の操作、フォーム入力、onChangeなどのキーワードがあればClient Scriptを考えます。

CADでは、より実装寄りに、実行タイミング、サーバーサイド処理、画面以外の登録経路、GlideAjaxのような橋渡しも含めて問われることがあります。まずは「どこで動く処理か」を取り違えないことが大切です。

FAQ

まとめ

Client ScriptとBusiness Ruleは、どちらもJavaScriptを使えます。しかし、Client Scriptは画面側、Business Ruleはサーバー側という大きな違いがあります。

実務で迷ったら、「これは利用者の入力中に助ける処理か、それとも保存されるデータを守る処理か」を確認してください。この判断軸を持つと、スクリプトの置き場所を間違えにくくなります。