担当割り当て運用手順書：グループを変えられないのはBusiness Ruleが止めている

確認した環境：ServiceNow の PDI（Personal Developer Instance）、Zurich リリースの OOTB（初期設定）。2026-07-08 確認。時刻はすべて UTC で記載します。

1. 目的・背景

この記事は、ServiceNow で Incident を1件新規に起票します。そのうえで 担当者（assigned_to）が自動で入る → state が自動で進む → 担当グループ（assignment_group）を手で変えようとすると拒否される → 所属の合う別グループなら成功する、という一連の流れを実際に動かして確認した運用手順書です。担当割り当ては ITSM 運用の入口で必ず当たる部分ですが、「誰が担当を決めているのか」「なぜ勝手に状態が進むのか」「なぜグループを変えられないのか」でつまずきやすいところでもあります。

今回いちばん確かめたかったのは、incident の担当を実際に決めているのは Assignment Rule（sysrule_assignment）ではなかったという点です。このPDIでは incident 向けの Assignment Rule は6件すべて無効になっていて発火しません。代わりに Data Lookup（Assignment Lookup）が挿入時に担当者を埋めていました。この非対称な状態を出発点に、担当が入ったあとに連鎖して起きる自動遷移と、グループ変更が中止される仕組みまでを、1件の Incident（INC0010021）で最後まで動かして確認しています。

今回実走した Incident のフォームが次の画面です。category=Inquiry / Help、subcategory=Email で作成した直後に、Assigned to に Fred Luddy が入りました。State も In Progress まで進んでいます。

想定読者

この記事は、ServiceNow で Incident の担当割り当て運用を担当する人を想定しています。担当者やグループが「思ったとおりに入らない・変えられない」ときに何を確認すればよいかを手順として持っておきたい人にも向けています。sysrule_assignment や Data Lookup といったテーブルの構造そのものを先に理解したい場合は、担当割り当ての設計を扱った別記事（担当割り当ての仕組みと構造の設計書）を参照してください。あわせて読むと前提がつながります。この手順書が扱うのは「実際に動かすと何が起きるか」です。

2. 前提整理・全体フロー

担当割り当てを動かす2つの系統

ServiceNow で担当割り当てに関わる仕組みは1つではありません。今回関係したのは2つの系統です。担当グループを決める Assignment Rule（sysrule_assignment） と、レコード挿入時に条件一致で担当者などを埋める Data Lookup（dl_definition / dl_u_assignment） です。ポイントは、この2つが incident に対してまったく別の状態にあったことです。

まず incident 向けの Assignment Rule を一覧で確認すると、6件すべてが Active=false（無効）でした。つまり incident を作っても Assignment Rule は発火しません。Assignment Rule そのものの位置づけは公式の Assignment rules module（Zurich） に、incident 向けにルールを定義する手順は Define assignment rules for incidents（Zurich） にまとまっています。

一方で Data Lookup 側は有効でした。Data Lookup Definitions（dl_definition）は3件すべて active でした。そのうち Assignment を決める定義（matcher=dl_u_assignment）は、挿入時に走る設定（run_on_insert=true）になっています。Data Lookup の仕組み自体は公式の Data lookup and record matching support（Zurich） が詳しく説明しています。

この2系統のどちらが優先されるかは公式の Precedence between data lookup, assignment, and business rules（Zurich） にも整理されています。役割と、このPDIでの状態を整理すると次のとおりです。

今回実走した担当割り当ての全体像

New で起票した Incident に対して、どの系統が発火し、そのあと何が連鎖するのか。今回動かした流れを1枚の図に整理すると次のとおりです。担当者が入る → state が自動で進む → グループ変更が一度拒否される → 所属の合うグループなら成功する、という順序で進みます。

この記事（無料部）で分かること

• incident の担当を実際に決めているのは Assignment Rule ではなく Data Lookup だった、という前提の見分け方

• Data Lookup の一致条件（category / subcategory）に合わせて Incident を作ると担当者が自動で入る手順

• 担当割り当てにまつわる自動連鎖の全体像（担当セット → state 自動遷移 → グループ変更の可否）

3. 操作手順

ここからは操作を番号付きで並べます。各ステップは、実施者／画面への行き方／入力項目と値／押すボタン（または API）／成功条件／注意点の順です。今回はフォームと同じフィールドを REST API（Table API）で直接作成・更新して確認しました。画面から同じ項目を入力する手順に読み替えて書いていますが、フォーム上のボタン固有の動作（Client Script や UI Policy による即時バリデーションなど）は検証範囲外です。

1) Incident 起票で Data Lookup を発火させる

• 実施者：Incident を起票する担当者、または代行入力するサービスデスク担当

• 画面への行き方：アプリケーションナビゲーターで「Incident > Create New」から新規作成

• 入力項目と値：

• Short description（内容の要約）

• Category=Inquiry / Help（内部値 inquiry）

• Subcategory=Email（内部値 email）

• 押すボタン（または API）：フォームで入力して「Submit」（今回は Table API での作成で確認）

• 成功条件：作成直後に Assigned to に Fred Luddy が自動で入り、Assignment group は空のままであること。あわせて State が In Progress になっていること

• 注意点：担当者を埋めているのは Assignment Rule ではなく Data Lookup。category と subcategory が Data Lookup の一致行の条件と合ったときだけ発火する。条件から外れた組み合わせで作ると担当者は入らない

今回一致した Data Lookup の行は1行でした。入力列は category=Inquiry / Help・subcategory=Email、結果列は assigned_to=Fred Luddy・assignment_group=空（order=100、active）です。この行のフォームが次の画面です。

INC0010021 を category=inquiry・subcategory=email で作成したところ、この行の結果列がそのまま反映されました。Assigned to に Fred Luddy が自動でセットされ、Assignment group は空のままです。担当グループを決める Assignment Rule ではなく、担当者を直接決める Data Lookup が動いたことになります。ここが今回の運用のいちばんの入口です。

無料部はここまでです。有料部では、担当者が入ったことで State がひとりでに進んだ理由を確認します。担当グループを手で変えようとして 403 で拒否された実測とその原因、そして所属の合う別グループなら通った流れまで、操作のたびに何が自動で動くかを実測つきで確認します。

• Data Lookup が担当者を埋めた直後に、State が New から In Progress へ自動遷移した理由（連動する Business Rule）

• assignment_group を非メンバーのグループへ変更すると HTTP 403 で更新全体が中止される実測と、その原因の Business Rule

• 所属の合うグループへ変更すると成功し、担当者は自動クリアされず reassignment_count だけが加算される実測

• 操作と結果の時系列まとめ、よくあるつまずきとリカバリ表