似て見えるが役割が違う
ServiceNowを触り始めた頃、誰もが一度は迷います。
「レコード更新をきっかけに処理を走らせたい。FlowでもBusiness Ruleでもできそう。じゃあ両方で保険をかける？」
これ、やるとだいたい後で爆発します。
理由はシンプルで、FlowとBusiness Ruleは似た目的に見えて、守備範囲と実行の性質が違うからです。混ぜた瞬間に、処理の責任範囲が曖昧になり、二重実行・順序競合・性能劣化・原因不明の挙動が出やすくなります。
この記事では、CSA学習者が「暗記」ではなく「仕組み」として整理できるように、実務で起きがちな事故パターンと、混ぜないための判断基準を具体例で解説します。
本番形式で慣れるのが合格への近道。UdemyのServiceNow模擬問題集を人気順で一覧比較できます👇
FlowとBusiness Ruleの前提整理
Flowは業務プロセスの自動化を組み立てる
Flow Designerは、トリガーとアクションを繋いで業務の流れを作る仕組みです。今はWorkflow Studioの体験に統合されつつありますが、考え方は同じで、プロセスを見える形で設計し、変更しやすくする方向に寄っています。
ServiceNow公式ドキュメントでは、基本的にBusiness RuleよりFlow Designerを優先する考え方が示されていて、例外条件も明記されています。
Business Ruleはデータベース操作に密着したサーバー処理
Business Ruleは「いつ」「どのDB操作で」「どのタイミングで」実行するかを持つサーバーサイドスクリプトです。display / before / after / async など、DB操作と密着したタイミング制御ができます。
加えて、スクリプトやエンジンの実行順序という観点でもBusiness Ruleは重要な登場人物で、特にasyncは「スケジューラで実行される」など、動きが一段違います。
混ぜると起きる事故パターン
二重実行で同じ更新が二回走る
典型例はこれです。
- Business Ruleで「assignment_groupが空ならAを入れる」
- Flowでも「assignment_groupが空ならBを入れる」
条件は同じでも、実行のタイミングや順序がズレて、意図しない上書きが起きます。最初は「たまに起きる」ので余計に厄介で、再現性が低く見えます。
結果として、ユーザーからは「勝手に割り当てが変わる」「更新したのに戻る」と見え、調査側はログと履歴を追う地獄になります。
実行順序が読めずレースコンディションになる
Business RuleにはOrderがあり、before/after/asyncの区分もあります。一方Flowはプロセスとして読みやすい反面、同じレコード更新を起点に複数の自動化が絡むと、期待通りの順序で揃わない状況が起きます。
「Business Ruleでフィールドを整形してからFlowで通知したい」みたいな設計を混ぜると、通知側が“整形前の値”を拾うことがあり、事故になります。
トランザクション境界がズレて整合性が崩れる
ServiceNow公式は、FlowよりBusiness Ruleが必要なケースとして、次を挙げています。
- 他のBusiness Ruleと特定の順序で動かす必要がある
- 同一スレッドで、DB書き込みの直前・直後に即時実行したい
- ロジックがScript Include呼び出しのみ
つまり、DB更新の瞬間に一体化した処理はBusiness Ruleが得意です。ここを無理にFlowと混ぜると、コミット前後のズレが出て、関連レコード更新や参照整合性が崩れやすくなります。
パフォーマンス劣化の原因が見えにくい
Business Ruleは「このテーブルのこのタイミングで動く」と割り切れる反面、数が増えると管理が地獄になりがちです。逆にFlowは実行履歴を追いやすいですが、混ぜると原因が二箇所に分散します。
ユーザー体験としては「フォーム保存が遅い」だけが見え、調査側は
- before BRが重いのか
- after/async BRが詰まってるのか
- Flowのアクションが遅いのか
- そもそも二重に走ってるのか
を全部疑う必要が出てきます。
アップグレード時に直す場所が倍になる
FlowとBusiness Ruleはアップグレード影響の出方が違います。Flow側のアクションやコネクタ更新、BR側のスクリプト互換など、修正ポイントが増えます。
同じ業務ルールを二重に持つ設計は、それだけで将来の変更コストが倍です。
使い分けの判断基準
ここだけ押さえると、混ぜる確率が一気に下がります。
Flowを第一候補にする場面
- 承認、通知、タスク作成、分岐、待ち時間など、業務プロセスを表現したい
- 将来的に担当者が変わっても追えるように、見える化しておきたい
- IntegrationHubなどを含めた“処理の流れ”として管理したい
- 条件が増減する可能性が高く、後から調整されやすい
公式としても、原則Flow優先の方針が明示されています。
Business Ruleを選ぶほうが安全な場面
ServiceNow公式が例外として挙げる観点を、そのまま「判断の柱」にするとブレません。
- 他のBusiness Ruleと順序を揃えたい
例 既存BRの後にだけ走らせたい、間に差し込みたい - DB書き込み直前直後に同一スレッドでやりたい
例 直前に必須整形、直後に整合性チェック - Script Includeを呼ぶだけの薄い処理
例 共通関数へ委譲してBRは入口に徹する
そして、BRの種類と特性も理解しておくと「混ぜる」誘惑が減ります。BRにはdisplay/before/after/asyncがあり、asyncはスケジューラ実行など挙動が変わります。
現場で効く設計テンプレと実装例
テンプレは責任分離で考える
混ぜないコツは「どちらでやるか」より、責任範囲を最初に切ることです。
- データの正しさを守る層
例 値の正規化、必須フィールド、整合性
→ Business Ruleで最小限に寄せることが多い - 業務としての流れを作る層
例 承認、通知、関連タスク、分岐、待機
→ Flowに寄せることが多い
両方を使うなら「同じ条件で同じフィールドを触らない」ルールを自分に課すだけで事故は激減します。
実装例 インシデントでの典型パターン
要件
- インシデント登録時、短すぎる短文はdescriptionに追記して整形したい
- 高優先度ならチームへ通知し、必要なら子タスクを作りたい
設計
- Business Ruleでdescription整形だけを行う
- beforeにして、DBへ書き込む前に確実に整形
- Flowで高優先度の通知とタスク作成
- プロセスとして見える化して運用が追える
この分け方だと、Flow側は“整形済みのdescription”を使えるので、通知文の揺れも減ります。
逆に、整形も通知も両方Flowでやる、あるいは両方BRでやるより、変更点が追いやすくなります。
禁止ルールを決めると迷いが消える
実務では次の「自分ルール」を決めると、混在が止まります。
- 同じ条件で同じフィールドを更新する自動化を二重に作らない
- データ整形はBR、業務の流れはFlowに寄せる
- 例外的にBRを使うのは、公式の例外条件に当てはまる時だけにする
- 既存がBR中心のテーブルでは、むやみにFlowを足さず、まず責任範囲の整理をする
学習と試験対策のまとめ Udemy活用のコツ
CSA視点で理解しておくと強いポイント
CSAの学習では、次の理解があると「選択肢の違い」が読みやすくなります。
- Business RuleはDB操作タイミングに密着し、before/after/asyncなどがある
- asyncは同期処理ではなく、スケジューラ実行など性質が違う
- Flowは原則推奨だが、順序や同一スレッド実行など例外がある
暗記で「Flowが新しいから正解」ではなく、なぜ例外があるのかまで理解すると、設問の意図が取りやすくなります。
体系的に学べる教材の一例としてUdemy
独学だと、FlowとBusiness Ruleが「どっちも自動化」に見えて混乱しがちです。
その場合は、Udemyで「Flow DesignerとBusiness Ruleの役割」「実行タイミング」「設計の責任分離」を一連で扱う講座を選ぶと、点の知識が線になります。
選ぶ時のコツは、機能紹介だけではなく
- いつFlowを選ぶか
- いつBRが必要になるか
- 混在させない設計の考え方
を“判断基準”として説明しているものを探すことです。
本番形式で慣れるのが合格への近道。UdemyのServiceNow模擬問題集を人気順で一覧比較できます👇
まとめ
FlowとBusiness Ruleを混ぜてはいけない最大の理由は、「同じことができるから」ではなく、実行の性質が違うのに、責任範囲を曖昧にしてしまうからです。
- Flowは業務プロセスを見える形で自動化するのが得意
- Business RuleはDB操作に密着したタイミング制御や順序制御が得意
- 公式も原則Flow優先を示しつつ、順序や同一スレッド実行などの例外を明記している
混在を避ける一番のコツは、「どっちが正しいか」ではなく、どこまでをBRに責任を持たせ、どこからをFlowに責任を持たせるかを先に決めることです。
同じ条件で同じフィールドを二重に触らない。これだけでも事故は大きく減ります。
