自動割り当ての2つの仕組み（Assignment Rule / Data Lookup）

ServiceNow で Incident や Problem を登録すると、担当グループ（Assignment group）や担当者（Assigned to）が自動で入ることがあります。この「自動で決まる」裏側には2つの仕組みがあります。おもに Assignment Rule（sysrule_assignment） と Data Lookup（dl_definition / dl_matcher） です。

この記事では、自動割り当てをプロセス論だけで説明しません。実際の sysrule_assignment テーブルと dl_definition / dl_matcher テーブルを起点にします。ルールがどのフィールドを持ち、どんな条件で走り、どちらの担当先をセットするのかを、PDI の OOTB レコードで確認します。

この記事は、ServiceNow の Incident は触ったことがあるが、「担当が自動で決まる仕組み」をテーブル構造から理解したい人を想定しています。管理者・開発者が実機で確認するときに見るべきポイントは、Assignment Rule の継承・主要フィールド・条件です。あわせて、Data Lookup の定義とマッチ表、2つの使い分けも順に確認します。

この記事で分かること

• Assignment Rule（sysrule_assignment）が sysrule（Rule）を継承する「設定（メタデータ）」であること

• Assignment Rule の主要フィールド（table / condition / group / user / script / order）

• 割り当てが走る条件（未割当のときだけ・order 最小の1件）

• Data Lookup（dl_definition）と、マッチ表（dl_matcher 系）の関係

• Assignment Data Lookup（dl_u_assignment）が category などから担当を引く構造

• Assignment Rule と Data Lookup の使い分け

自動割り当て（Assignment Rule / Data Lookup）とは

ServiceNow の自動割り当てとは、タスク系レコード（Incident / Problem / Change など）の保存時に動く仕組みです。条件に応じて、担当グループや担当者を自動でセットします。ノーコードで「このカテゴリならこのグループ」といった割り当てを定義できます。

代表的な手段が2つあります。

• Assignment Rule（sysrule_assignment） … 条件（フィルタ）に一致したら、決まった group / user を1組セットする。

• Data Lookup（dl_definition ＋ マッチ表） … 入力列（category など）の値が一致する行を「表」から探す。その行の結果列（assignment_group など）をセットする。

どちらも「担当を自動で決める」点は同じですが、条件の書き方（フィルタ vs 表の完全一致）と、セットできる値の数（1組 vs 複数列）が違います。この記事では両方をテーブルから確認します。

Assignment Rule は「設定（メタデータ）」として保存される

まず、Assignment Rule がどこに位置するかを継承関係で確認します。

今回確認した PDI（Zurich / OOTB）では、sysrule_assignment（Assignment Rule）は sysrule（Rule）を継承していました。sysrule はさらに sys_metadata（Application File）を継承していました。つまり Assignment Rule は Incident のような「業務レコード」ではなく、sys_metadata 配下の「設定（メタデータ）」として保存されます。order や name は親の sysrule 側で持ち、割り当て先の group / user は sysrule_assignment 側の固有フィールドです。

Data Lookup も同じく設定側です。dl_definition（Data Lookup 定義）と dl_matcher（マッチ表の基底）は、どちらも sys_metadata を継承していました。実際のマッチ行は dl_matcher を継承した個別テーブル（後述の dl_u_assignment など）に入ります。今回の PDI では、dl_matcher の直接の子クラスは3つ（dl_u_priority / dl_u_assignment / dl_problem_priority）でした。

クラス定義は、次のURLで確認できます（先頭の <YourInstance> は自分のインスタンスに置き換えてください）。

https://<YourInstance>/sys_db_object_list.do?sysparm_query=nameINsysrule_assignment,dl_definition,dl_matcher

Assignment Rule の主なフィールド

Assignment Rule は、どのテーブルのどんな条件で、どの担当に割り当てるかを持ちます。今回の PDI では固有フィールドは8（active, table, condition, match_conditions, group, user, script, sys_id）でした。

役割で分けると4つです。「対象（table）」「条件（condition / match_conditions）」「結果（group / user、または script）」「優先順位（order）」です。group は sys_user_group（担当グループ）、user は sys_user（担当者）を参照します。条件で決めきれない複雑な割り当ては script フィールドにロジックを書いて決めることもできます。

実際の OOTB ルールを一覧で見ると、対象テーブルや条件のバリエーションが分かります。

今回確認した PDI では、Assignment Rule は全17件、うち active は6件でした。代表的な active ルールと条件は次のとおりです。

注目したいのは、incident の OOTB ルールが今回の PDI ではすべて inactive だった点です。しかも「Assign to shift member - Subflow」「VIP Callers - Subflow」のように、名前に Subflow が付くものが目立ちます。少なくとも今回確認した PDI（Zurich / OOTB）では、こういう様子が観察できました。incident の新しい割り当ては Assignment Rule ではなく Flow Designer の Subflow 側に寄せられているという様子です（一般仕様としての断定はしません）。

一方 problem は Database / Software / Network の3ルールが active のままでした。ほかに change_request 向けの「Assign unauth change to chg management」も active なルールでした。std_change_proposal 向けの「Standard Change Proposal」も同様です。いずれも Change Management に割り当てます。

対象テーブルの分布

incident 6 / problem 3 / interaction 2 / change_request 1 / kb_feedback_task 1
std_change_proposal 1 / sc_req_item 1 / ticket 1 / release_phase 1

実際の1ルールのフォームを見ると、条件（Conditions）と割り当て先（Group）がどう設定されているかが分かります。

Assignment Rule の一覧は、次のURLで確認できます。

https://<YourInstance>/sysrule_assignment_list.do?sysparm_query=ORDERBYtable

公式の Assignment rules module（Zurich） に、Assignment Rule で assigned_to / assignment_group を自動設定する考え方が説明されています。

Assignment Rule に紐づく周辺設定

sysrule_assignment には read / write / create / delete / query_range の5種類の Access Control が設定されていました。一方、sysrule_assignment に直接紐づく active な Business Rule・UI Action はいずれも0件でした。

割り当てが走る条件（未割当・order 最小の1件）

Assignment Rule は、条件に一致すればいつでも上書きするわけではありません。走る条件には決まりがあります。

公式ドキュメントによると、Assignment Rule は次の条件で走ります（これは PDI 実測の数値ではなく動作仕様です）。

• タスクレコードが作成・更新されたときに評価される（フォーム上の未保存の変更には適用されない）

• レコードが未割当のときだけ走る（assigned_to / assignment_group が両方とも空）。既存の割り当ては上書きしない

• 複数のルールが条件に一致した場合、order（優先順位）が最小のルールだけが走る

だから、広い条件のルールには大きい order を付けて「最後の受け皿」にするのが定石です。今回の PDI でも、incident の "Service Desk"（条件 active=true と広い）は order=1000 と大きく、最後に効くように設計されていました。一方、具体的な条件のルール（Network など）は order=100 で先に効きます。

公式の Define assignment rules（Zurich） に、未割当のときだけ走る点や order による優先順位の考え方がまとまっています。

Data Lookup（表で担当を引く仕組み）

もう一つの自動割り当てが Data Lookup です。Assignment Rule が「条件→1組の割り当て」なのに対し、Data Lookup は「入力列の値が一致する行を表から探し、その行の結果列をセットする」仕組みです。

Data Lookup は2つのテーブルで構成されます。

• dl_definition（Data Lookup 定義） … どの source_table（対象）に対して、どの matcher_table（マッチ表）を引くかを決める。run_on_insert / run_on_update / run_on_form_change で走るタイミングを制御する。

• マッチ表（dl_matcher を継承した個別テーブル） … 入力列（マッチ条件）と結果列（セット先）を持つ「表」。1行＝1つの対応関係。

Data Lookup 定義・マッチ表の固有フィールド

• dl_definition … 固有8（name, source_table, matcher_table, active, run_on_insert, run_on_update, run_on_form_change, sys_id）

• dl_matcher（マッチ表の基底）… 固有3（active, order, sys_id）。入力列・結果列は dl_u_assignment のような子クラス側がそれぞれ個別に持ちます

今回確認した PDI（Zurich / OOTB）では、dl_definition は3件あり、いずれも active でした。

このうち Assignment Lookup は、source=incident・matcher=dl_u_assignment という定義でした。定義フォームを見ると、対象テーブルとマッチ表、走るタイミングのフラグが確認できます。

マッチ表 dl_u_assignment の実際の行を開きます。入力列（category / subcategory / location / cmdb_ci）と結果列（assignment_group / assigned_to）を持っていることが分かります。今回の PDI に入っていた1行は、category=Inquiry / Help と subcategory=Email が一致する行です（order=100）。一致したら assigned_to=Fred Luddy をセットする対応でした。

ポイントは、Data Lookup は「表の行を増やすだけ」で割り当てパターンを追加できることです。スクリプトを書かずに、業務担当者でも category と担当の対応表をメンテナンスできます。

また Data Lookup は assignment だけでなく priority（impact + urgency → priority）にも使われます。今回の PDI では Priority Lookup（source=incident・matcher=dl_u_priority）が存在しました。あわせて Priority Problem Lookup（source=problem・matcher=dl_problem_priority）も存在しました。

Data Lookup 定義は、次のURLで確認できます。

https://<YourInstance>/dl_definition_list.do?sysparm_query=active=true

公式の Create custom data lookups（Zurich） に、Source Table とマッチ表（dl_matcher を継承）で値を自動設定する考え方が説明されています。

Data Lookup に紐づく周辺設定

dl_definition には Access Control が3件ありました。dl_ プレフィックスのテーブル全体でみると、Access Control は32件でした。

Assignment Rule と Data Lookup の使い分け

2つは似ていますが、向いている場面が違います。

• Assignment Rule … 条件はフィルタ（範囲・ドットウォーク・スクリプトも可）で柔軟。結果は group / user の1組。担当先「だけ」を、複雑な条件で決めたいとき向き。

• Data Lookup … 条件は入力列の完全一致（表の行）。結果は行の複数列をまとめてセットできる（assignment_group だけでなく assigned_to や priority も）。「対応表」で運用したい・コードを書かずに増やしたいとき向き。

なお、Assignment Rule・Data Lookup・Business Rule が同じレコードに関わる場合の優先順位は、公式の Precedence between data lookup, assignment, and business rules（Zurich） にまとめられています。実環境で両方を使う場合は、どちらが先に値をセットするかをこのドキュメントで確認するのが安全です。

ServiceNow の自動割り当てのポイント

• 自動割り当ての中心は Assignment Rule（sysrule_assignment） と Data Lookup（dl_definition ＋ マッチ表） の2つ。どちらも sys_metadata 配下の「設定」として保存されます。

• Assignment Rule は table / condition / group / user / script / order を持ちます。未割当のときだけ・order 最小の1件が走ります。既存の割り当ては上書きしません。

• 今回確認した PDI では Assignment Rule は全17件（active 6件）。incident の OOTB ルールは全て inactive で、名前に Subflow が付くものが多く、新しい割り当ては Flow Designer 側に寄っている様子でした（断定はしません）。

• Data Lookup は dl_definition が source_table とマッチ表を結び、マッチ表（dl_matcher 系）の入力列が一致した行の結果列をセットします。今回の PDI では dl_definition 3件（すべて active）でした。

• Assignment Data Lookup（dl_u_assignment）は、category / subcategory / location / cmdb_ci を入力に使います。結果は assignment_group / assigned_to です。表の行を増やすだけで割り当てパターンを追加できます。

• 使い分けは「複雑な条件で担当だけ決める→Assignment Rule」「対応表でノーコード運用→Data Lookup」。両方使うときは優先順位を公式ドキュメントで確認します。

自動割り当てを調べるときは、まず「Assignment Rule なのか Data Lookup なのか」を切り分けます。Assignment Rule なら table / condition / order を見ます。Data Lookup なら dl_definition の source/matcher とマッチ表の入力列・結果列をセットで見ると分かりやすくなります。

実機で気づいたこと

• active な Assignment Rule 6件のうち「Knowledge Feedback Task Assignment」だけは group / user が空で、代わりに script 側に割り当てロジックを書いていました。条件だけでなく結果側もスクリプトに任せられる、という柔軟性の実例です。

• マッチ表の基底 dl_matcher 自体の固有フィールドはわずか3（active, order, sys_id）で、入力列・結果列は dl_u_assignment のような子クラス側に個別に持たせる作りでした。基底に入出力列を持たせないことで、優先度用・割り当て用など性質の違うマッチ表を増やしても基底のスキーマを汚さずに済む、という設計に見えます。

• sysrule_assignment には Access Control が5件ある一方、直接紐づく active な Business Rule・UI Action は0件でした。Assignment Rule 自体は「条件と結果を持つ設定レコード」に徹していて、実行そのものはプラットフォーム側のコアエンジンが担っていると考えると腑に落ちます。

次に読むなら

次に確認するなら2つあります。Flow Designer の Subflow による割り当て（今回 incident のルール名に出てきた Subflow 系）です。もう1つは AWA（Advanced Work Assignment）によるキュー・能力ベースの割り当てです。「条件ベースの Assignment Rule / Data Lookup」と「フロー・キューベースの Subflow / AWA」をどう使い分けるかが論点です。割り当て設計を考えるうえで判断の分かれ目になります。これらは本記事の「割り当てが走る条件」「使い分け」で触れた仕組みの先にあたり、別記事で扱う予定です。

用語

• PDI：Personal Developer Instance（無料の検証用インスタンス）

• OOTB：Out of the Box（初期設定のまま）

• Assignment Rule：条件に応じて担当グループ・担当者を自動セットするルール（sysrule_assignment）

• Data Lookup：入力列の一致する行を表から探して結果列をセットする仕組み（dl_definition ＋ マッチ表）

• Matcher Table（マッチ表）：dl_matcher を継承し、入力列と結果列を持つ対応表（例 dl_u_assignment）

• order：複数ルール一致時の優先順位（小さいほど先に走る）

自分の環境で確認するときのURL

先頭に自分のインスタンスを付けると、同じ画面が開けます。

クラス定義           : sys_db_object_list.do?sysparm_query=nameINsysrule_assignment,dl_definition,dl_matcher
Assignment Rule 一覧 : sysrule_assignment_list.do?sysparm_query=ORDERBYtable
固有フィールド       : sys_dictionary_list.do?sysparm_query=name=sysrule_assignment^elementISNOTEMPTY
Data Lookup 定義     : dl_definition_list.do?sysparm_query=active=true
マッチ表（割り当て） : dl_u_assignment_list.do

検証範囲とおことわり

• 確認した範囲：sysrule_assignment / dl_definition / dl_matcher のクラス階層です。固有フィールド数（sysrule_assignment 8 / dl_definition 8 / dl_matcher 3）も確認しました。加えて、Assignment Rule 全17件の実データ（table / active / order / group / condition）を確認しました。dl_definition 全3件、dl_u_assignment のマッチ行1件、ACL 件数も確認しました。すべて PDI（Zurich / 2026-06-20 確認）の OOTB で取得しています。割り当ての動作仕様（未割当のみ・order 最小・実行タイミング）は servicenow.com 公式 Zurich ドキュメントで確認した一般仕様です。

• 確認していない範囲（断定しません）：割り当てを実行する内部エンジン（Business Rule の正体）と script フィールドの具体的な挙動です。ほかに、Assignment Rule・Data Lookup・Business Rule の実環境での優先順位の挙動は確認していません。Flow Designer Subflow と AWA（Advanced Work Assignment）との詳細な使い分け、Data Lookup のキャッシュ・大量行時の性能も確認していません。これらは別記事で扱います。