ServiceNowのBusiness RuleとFlow Designerの違い｜自動化で迷わない使い分け

ServiceNowで自動化を作るとき、Business Rule と Flow Designer のどちらを使うべきかで迷うことがあります。どちらも「レコードが作成・更新されたら何かを実行する」ことができるため、最初は役割が重なって見えます。

結論から言うと、Business Ruleはレコード操作に近いサーバー側の制御で、Flow Designerは業務プロセスを見える形で組み立てる自動化です。実務では、データの整合性や厳密な実行タイミングを重視するならBusiness Rule、承認・通知・タスク作成・連携などの業務フローを見える化したいならFlow Designerが向いています。

Flow Designer・業務機能の理解をCSA模試で確認する
Flow、Workflow Studio、Platform機能の使い分けを問題形式で確認できます。

Business RuleとFlow Designerの違いは「データ制御」か「業務フロー」か

両者の違いは、実行できることだけでなく、どのレイヤーの自動化として設計するかにあります。

Business Ruleはレコード保存の近くで動くサーバー側処理

Business Ruleは、対象テーブルのレコードがinsert、update、delete、queryされるタイミングに合わせて動くサーバー側のルールです。before、after、async、displayなどの実行タイミングを選び、条件に合うとスクリプトで処理を行います。

たとえば、保存前に値を補正する、特定条件ではエラーにする、保存後に関連レコードへ値を反映する、といった処理はBusiness Ruleで考えやすい領域です。データの整合性に近い場所で動くため、設計を間違えると画面、API、インポート、Flowなど複数の入口へ影響します。

この影響範囲の広さが、Business Ruleの強みでもあり怖さでもあります。短い処理でも、条件が広すぎる、実行順序が悪い、同じレコードを再更新して再帰的に動く、といった問題が起きることがあります。

before / after / async のざっくり判断

// before Business Rule の考え方
// 保存前に current の値を整える場合、current.update() は不要です。
if (current.priority == 1 && !current.u_reason) {
  gs.addErrorMessage('High priority requires a reason.');
  current.setAbortAction(true);
}

// 値を補正するだけなら、保存前の current に代入する
current.short_description = (current.short_description || '').trim();

Flow Designerは業務プロセスを見える形で自動化する

Flow Designerは、トリガー、条件、アクションを組み合わせて業務プロセスを作るための機能です。承認を回す、通知を送る、Catalog Taskを作る、外部サービスへ連携する、といった処理を視覚的に組み立てられます。

Flow Designerが向いているのは、関係者に処理の流れを説明したい自動化です。画面上で「どの条件で、どのアクションが実行されるか」を追いやすいため、運用担当者や業務部門と会話しながら改善しやすくなります。

一方で、Flow Designerは何でも置き換えられる万能機能ではありません。保存前に値を厳密に整える、テーブルの根本的な整合性を守る、低レイヤーの処理を短く確実に実行する、といった場面ではBusiness Ruleのほうが自然な場合があります。

Flow Designerで必ず見るべき運用ポイント

• トリガー条件: どのテーブルの、どの更新で動くのかを狭くします。
• 実行ログ: 失敗時にどのアクションで止まったかを追えるようにします。
• サブフロー: 複数のフローで再利用する処理は切り出します。
• 実行ユーザー: Flowがどの権限で処理するかを確認します。

実務ではどう選ぶべきか

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

1. その処理はレコード保存の前後で厳密に制御すべきか
2. 業務担当者に処理の流れを説明する必要があるか
3. 承認、通知、タスク、外部連携が中心か
4. スクリプトでしか実現しにくい細かい制御が必要か
5. 同じ処理がBusiness RuleとFlowで重複していないか

保存前に必ず値を補正したい、必須チェックを独自条件で行いたい、関連レコードの整合性を保ちたい場合はBusiness Ruleを検討します。申請後に承認を回す、担当者へ通知する、タスクを作る、連携先へ送る場合はFlow Designerを検討します。

同じ処理を二重に作らない

実務でよくある失敗は、Business RuleとFlow Designerの両方で似た処理を作ってしまうことです。たとえば、Business Ruleでも通知し、Flow Designerでも通知する。Business Ruleでも状態を変え、Flow Designerでも状態を変える。このような重複は、原因調査を難しくします。

特に、ある更新をきっかけにFlowが動き、そのFlowの更新でBusiness Ruleが動き、さらに別のFlowが動くような構造になると、処理の見通しが悪くなります。設計段階で「データ制御はBusiness Rule」「業務フローはFlow Designer」のように責務を分けておくことが大切です。

よくある失敗例

• after Business Ruleでcurrent.update()を呼ぶ: 同じレコードの再更新で再帰処理や二重実行の原因になります。
• Flowのトリガー条件が広すぎる: どの更新でもFlowが走り、通知やタスクが重複します。
• 処理責務が重複する: Business Ruleでも状態を変え、Flowでも状態を変えると、原因調査が難しくなります。
• 実行ログを見ない: Flowは画面で作れる一方、失敗時は実行ログを見ないと原因が追えません。

トラブル時の確認順

自動化が思った通りに動かないときは、まず入口を分けて確認します。

1. どのテーブルの、どの操作がきっかけかを確認する
2. そのテーブルにBusiness Ruleがあるか確認する
3. Flow Designerのトリガー条件に一致しているか確認する
4. 同じフィールドを複数の自動化が更新していないか確認する
5. 実行ユーザー、権限、必須項目、状態遷移の条件を確認する

権限が絡む場合は、ServiceNowのACLとRoleの違い もあわせて確認すると、なぜ処理できないのかを切り分けやすくなります。

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

CSAでは、Flow Designerを「業務プロセスの自動化」として選ぶ問題が出やすい一方、Business Ruleはサーバー側のレコード処理として整理しておくと判断しやすくなります。

CADでは、Business Ruleの実行タイミング、条件、サーバーサイドスクリプト、Flow Designerとの責務分離がより重要になります。CISでは、対象アプリケーションの業務プロセスに沿って、どの自動化をどこに置くべきかという設計判断に近くなります。

FAQ

まとめ

Business RuleとFlow Designerは、どちらも自動化に使えます。しかし、Business Ruleはレコード操作に近いサーバー側制御、Flow Designerは業務プロセスの自動化と考えると整理しやすくなります。

実務で迷ったら、「これはデータの整合性を守る処理か、それとも業務の流れを進める処理か」を最初に確認してください。この判断軸を持つことで、自動化が増えても保守しやすい設計になります。