承認は1人1レコード（sysapproval_approver）

ServiceNow で Change Request や Catalog の申請を上げると、誰かに「承認してください」という依頼が飛びます。その承認依頼の実体がどこに保存され、何をきっかけに作られ、どう集計されるのかは、画面だけ見ていると意外と見えてきません。

この記事では、承認を機能論だけで説明しません。起点にするのは、実際の sysapproval_approver（Approval）テーブルです。承認を生む仕組み（Flow Designer の Ask For Approval）と、承認の状態を表す state を見ます。さらに、複数人をまとめる sysapproval_group（Group approval）との関係を追います。数値はすべて PDI（Zurich）の OOTB で確認した実測値です。

この記事は、ServiceNow の Incident や Change は触ったことがあるが、承認（Approval）の裏側のテーブル構造をこれから理解したい人を想定しています。管理者・開発者が実機で見るべきポイントは、sysapproval_approver の生成元と主要フィールドです。そこに state とグループ承認の集計ルールを重ねて確認します。

この記事で分かること

• 承認の実体が sysapproval_approver（1承認者＝1レコード）に保存されること。

• 承認を生む仕組み（今回の PDI では Flow Designer の Ask For Approval が中心）。

• sysapproval_approver の state（6値）と、承認対象の task 側 approval（4値）の違い。

• グループ承認 sysapproval_group が wait_for / reject_handling で集計を決めること。

• sysapproval（Approval for）→ task で「何を承認しているか」がつながること。

• 実機で確認するときに見るべき一覧URL。

承認エンジン（Approvals）とは

ServiceNow の承認とは、ある申請（Change / Catalog / Knowledge など）を進めてよいかを問い合わせる仕組みです。問い合わせる相手は、指定された人やグループです。その回答（承認 / 却下）が記録されます。承認待ちの「My Approvals」に並ぶ1件1件が、この記録にあたります。

その記録を格納する中心テーブルが sysapproval_approver（画面上のラベルは Approval）です。1人の承認者に対して1レコードが作られ、誰が・何を・どの状態で承認しているかを保持します。今回確認した PDI（Zurich / OOTB）では、sysapproval_approver に 751 件の Approval レコードがありました。うち state=Requested（承認待ち）が 390 件、Approved が 70 件です。

承認は申請レコードそのものの中ではなく、専用の sysapproval_approver に1承認者＝1レコードとして切り出して保存されます。だから1つの Change に複数人の承認が必要なら、その人数分の sysapproval_approver レコードが並びます。

承認まわりのテーブル関係

承認に関係するテーブルは、大きく「個別承認」「グループ承認」「承認対象」の3つに分けて見ると整理できます。

今回確認した PDI（Zurich / OOTB）では、それぞれ次の構造でした。

• sysapproval_approver（Approval） … super_class が空のルート基底テーブルでした。task は継承していません。固有フィールドは 24 です。

• sysapproval_group（Group approval） … こちらは task を継承していました（label は Group approval）。固有フィールドは 5 です。

• 承認対象 … sysapproval_approver の sysapproval（画面ラベル: Approval for）は task への参照です。「何を承認しているか」を指します。

つまり、個別承認（approver 単位）はルート基底の独立テーブル、グループ承認はタスクの一種です。性格の違うテーブルが組み合わさって、承認が表現されています。グループ承認の配下に、メンバー人数分の個別承認 sysapproval_approver がぶら下がる関係です。

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

https://<YourInstance>/sys_db_object_list.do?sysparm_query=name=sysapproval_approver^ORname=sysapproval_group

承認を生む仕組み（誰が sysapproval_approver を作るか）

承認レコードは人が手で作るより、申請のフローが自動で作るのが基本です。今回の PDI で「どこから承認が生まれているか」を実レコードから確認しました。

sysapproval_approver の実レコード 200 件を source_table で集計しました。内訳は change_request が 198 件、std_change_proposal が 2 件です。実際の承認レコードをたどると、sysapproval（Approval for）は CHG0000082 / CHG0000088 などの Change Request でした。approver は sys_user（例: cab approver, Ron Kettering）です。

生成元の観察（wf_activity と Flow Designer）

生成元については、次の2点が観察できました。

• レガシー Workflow の活動テーブル wf_activity は、この PDI では総件数 0 でした。つまり旧 Workflow 由来の承認活動は存在しません。

• 一方、Flow Designer の承認アクション定義には「Ask For Approval」（scope: Global, active）がありました。ほかにも Change 系の承認アクションが揃っています。Apply Change Approval Policy / Check Change for Approved User Approval が並んでいました。Cancel Approvals for record も同じく用意されています。

少なくとも今回確認した PDI（Zurich / OOTB）では、承認は主に Flow Designer の Ask For Approval が生成していました。その大半は Change 系のフローに紐づいています。実環境では、レガシー Workflow・スクリプト・手動追加など別の生成元が併存することもあります。生成元は source_table や生成元フィールドで確認するのが確実です。

公式の Ask for Approval action（Zurich） に、Flow Designer の Ask for Approval アクションが承認レコードをどう生成し、誰に・どんな状態で割り当てるかが説明されています。

sysapproval_approver の主なフィールド

sysapproval_approver は、「誰が・何を・どの状態で」承認しているかを表す項目を持ちます。役割で分けると、承認者・承認対象・状態・連携に整理できます。

主なフィールドの代表は次のとおりです。ラベルは画面上の表示名で、実機どおり記載します。

• approver（Approver → sys_user） … 承認する人。1レコード＝1承認者です。

• group（Group → sysapproval_group） … この承認が属するグループ承認。個別承認をグループに束ねます。

• sysapproval（Approval for → task） … 承認対象のレコード。task を参照し、Change なら change_request を指します。

• document_id（Approving）／ source_table … 承認対象を多態参照で指す項目と、その対象テーブル名。

• state（State） … 承認状態（後述）。

• comments（Comments） … 承認 / 却下時のコメント。

• wf_activity（Workflow activity）／ approval_source … 生成元のワークフロー活動や、承認の発生元を示す項目。

「誰が（approver）」「何を（sysapproval / document_id）」「どの状態で（state）」承認しているかが、1レコードに揃っています。だから承認待ち一覧を見るだけで、承認者・対象・状態が横並びで読み取れます。

全フィールドは、次のURLで一覧できます。

https://<YourInstance>/sys_dictionary_list.do?sysparm_query=name=sysapproval_approver^elementISNOTEMPTY

承認の状態（state）

承認の進み方は、state で表されます。task 系の State（new → in progress …）とは別の、承認専用の値です。

今回確認した PDI（Zurich / OOTB）の sysapproval_approver.state は、次の6値でした（value = label, sequence順）。

中心になるのは requested（承認待ち） で、ここから approved（承認）／ rejected（却下）に分かれます。条件が変わって承認が不要になれば cancelled（取消）や not_required（No Longer Required）になります。

task.approval とは別物

注意したいのは、承認対象の task 側にも approval というフィールドがある点です。こちらは not requested / requested / approved / rejected の4値です。個別の sysapproval_approver（6値）と、承認対象のレコード（4値）は別物になります。一覧で「承認待ちか」を見るときは、どちらの state を見ているのかを意識する必要があります。

承認の状態を実際のレコードで見ると、Approval フォーム上に Approve / Reject ボタンと、承認対象（Change Request）のサマリが表示されます。

state の選択肢は、次のURLで一覧できます。

https://<YourInstance>/sys_choice_list.do?sysparm_query=name=sysapproval_approver^element=state^inactive=false^ORDERBYsequence

公式の Classic approvals（Zurich） に、承認の基本的な仕組みと state の考え方が説明されています。

グループ承認（sysapproval_group）

複数人で承認するとき、1人ずつの sysapproval_approver をまとめる役が sysapproval_group（Group approval）です。グループ承認は「全員が承認すべきか、誰か1人でよいか」「1人が却下したら即否決か」といった集計ルールを持ちます。

今回確認した PDI（Zurich / OOTB）では、sysapproval_group は 127 件あり、集計を決める2つの choice フィールドを持っていました。

wait_for と reject_handling で結論が決まる

• wait_for（Wait for） … any は Anyone to approve（誰か1人で承認）。all は Everyone to approve（全員の承認が必要）。ほかに workflow ／ process_flow。

• reject_handling（Handle a rejection by） … reject と wait があります。reject（Rejecting group approval）は1人の却下でグループ全体を否決します。wait（Waiting for other responses before deciding）は他の回答を待ってから判断します。

グループ承認の「結論」は、個別承認の単純多数決では決まりません。wait_for / reject_handling の組み合わせで決まります。たとえば wait_for=all・reject_handling=reject なら「全員承認しないと通らず、1人でも却下したら即否決」という厳しめのルールになります。承認待ち一覧で複数の approver が同じ Change にぶら下がっているとき、その結論はこの設定次第で変わります。

実際の承認待ち一覧を見ると、1つの Change（例: CHG0030008）に複数の approver がぶら下がっています。Howard Johnson / Ron Kettering / Luke Wilson … といった承認者が Requested で並びます。これがグループ承認の実体です。

公式の Select an approval table（Zurich） に、どのテーブルで承認を管理するか（個別 / グループ）の選び方が説明されています。

sysapproval_approver に関わる周辺機能

承認の動きも、フィールド定義だけでは決まりません。承認時の処理や通知、権限など、複数の設定が組み合わさって動きます。大まかには、保存時の処理は Business Rule、Approve / Reject の操作は UI Action、承認依頼メールは Notification が担います。

今回確認した PDI（Zurich / OOTB・active 中心・2026-06-20 確認）では、sysapproval_approver に次のような設定が紐づいていました。

Notification が多い理由

特徴的なのは Notification が 13 件 と多いことです。Approval Request（承認依頼）／ Approval Rejected（却下）といった基本の通知があります。Catalog Approval Request ／ Contract Approval Request のように、承認対象ごとに通知が用意されているのが分かります。承認は「依頼が届いて初めて回る」仕組みなので、通知が厚いのは理にかなっています。

Business Rules・UI Actions・Notifications のほかにも、Client Scripts 1・UI Policies 2、Access Controls はテーブルレベル 5 ＋フィールドレベル 11、Choices（選択肢）11 件が sysapproval_approver に紐づいていました。承認のフォームは項目数のわりに ACL（Access Controls）が細かく分かれており、承認者以外が state を書き換えられないようにする制御が、テーブルとフィールドの両方に仕込まれていることがうかがえます。

ここで数えているのは、sysapproval_approver に直接紐づく設定だけです。実際の承認の挙動は、生成元のフロー（Ask For Approval）や、承認対象テーブル（change_request など）側の設定とも合わさって決まります。Approval テーブル単体だけを見て全体を判断しないようにします。

自分のインスタンスでは、次のURLで各一覧を開けます（先頭の <YourInstance> は置き換えてください）。

Business Rules : https://<YourInstance>/sys_script_list.do?sysparm_query=collection=sysapproval_approver^active=true
UI Actions     : https://<YourInstance>/sys_ui_action_list.do?sysparm_query=table=sysapproval_approver
Notifications  : https://<YourInstance>/sysevent_email_action_list.do?sysparm_query=collection=sysapproval_approver

ServiceNow における承認エンジンのポイント

• 承認の実体は sysapproval_approver（Approval） に「1承認者＝1レコード」で保存されます。今回の PDI では 751 件、うち Requested 390 件・Approved 70 件でした。

• sysapproval_approver は super_class が空のルート基底テーブル（task は継承しない）で、固有フィールドは24でした。一方 sysapproval_group は task を継承し、固有フィールドは5でした。

• 承認の生成元は、今回の PDI では Flow Designer の Ask For Approval が中心で、source_table は change_request が大半でした。レガシー Workflow の wf_activity は 0 件でした。

• state は6値（not requested / requested / approved / rejected / cancelled / not_required）。承認対象の task.approval（4値）とは別物なので、どちらを見ているか意識します。

• グループ承認 sysapproval_group は wait_for（any/all）と reject_handling（reject/wait） で結論の出し方を決めます。個別承認の単純多数決ではありません。

• sysapproval（Approval for）→ task で「何を承認しているか」がつながり、approver → sys_user で「誰が」が決まります。

承認を調べるときは、まず「この承認レコードは何（sysapproval / source_table）に対する、誰（approver）の、どの状態（state）の承認か」を読みます。そのうえで、sysapproval_approver 単体ではなく、上の生成元（Flow）、横の sysapproval_group、対象の task をセットで見ます。

実機で気づいたこと

• 個別承認 sysapproval_approver は task を継承しないルート基底テーブルなのに、複数人をまとめる sysapproval_group は task を継承しています。最初は逆ではないかと思いましたが、よく考えると筋が通っています。sysapproval_group は「承認をまとめて管理するタスク」そのものなので task の一種でよく、sysapproval_approver は「誰か1人の回答を記録する台帳」なので、タスクである必要がないのだと理解しました。

• レガシー Workflow の活動テーブル wf_activity が今回の PDI で総件数0件だったのは、少し意外でした。Workflow 由来の承認という話をネットではよく見かけますが、少なくとも今回の Zurich PDI では承認の生成が Flow Designer（Ask For Approval）に完全に置き換わっていて、旧方式の痕跡は残っていませんでした。ちなみに Ask For Approval のような Flow アクション定義自体は sys_hub_action_type_definition というテーブルに保存されています。生成元をたどるときはここも見る場所になります。

• sysapproval_approver には due_date（期限）や expected_start（開始予定）といった、期日を意識したフィールドがありました。承認は SLA のような厳密な期限管理の仕組みとは別物ですが、テーブル設計としては承認にも「いつまでに」を持たせられる作りになっています。実務で承認が滞留しているかを見るなら、state だけでなくこの期日系フィールドも合わせて確認すると良さそうです。

次に読むなら

承認全体がどこで誰に回り、なぜ止まるのかを先に俯瞰したい場合は、ServiceNow 承認（Approval）完全ガイド：申請はどこで誰に回り、なぜ止まるのか が入口になります。次に確認するなら、Flow Designer の Ask For Approval アクションの設定（承認者の指定方法・期日・条件）です。承認の委任（Delegate）や、承認対象である change_request 側の承認ポリシー（Change Approval Policy）も同じ流れで追えます。「承認を生むフロー」と「承認を集計するグループ」を分けて理解すると、承認が止まったときの調査が楽になります。これらは本記事の「承認を生む仕組み」「グループ承認」で触れた仕組みの先にあたり、別記事で扱う予定です。

用語

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

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

• Approval（sysapproval_approver）：個別承認のレコード（1承認者＝1件）

• Group approval（sysapproval_group）：複数の個別承認を束ねるグループ承認

• Ask For Approval：Flow Designer の承認アクション（承認レコードを生成）

• sysapproval（Approval for）：承認対象（task）への参照

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

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

テーブル定義       : sys_db_object_list.do?sysparm_query=name=sysapproval_approver^ORname=sysapproval_group
フィールド一覧      : sys_dictionary_list.do?sysparm_query=name=sysapproval_approver^elementISNOTEMPTY
state 選択肢        : sys_choice_list.do?sysparm_query=name=sysapproval_approver^element=state^inactive=false^ORDERBYsequence
承認待ち一覧        : sysapproval_approver_list.do?sysparm_query=state=requested
グループ承認        : sysapproval_group_list.do

検証範囲とおことわり

• 確認した範囲：sysapproval_approver / sysapproval_group の階層、固有フィールド数（approver 24 / group 5）、state 選択肢、主要フィールドと参照先、承認の生成元（source_table 集計・Flow アクション・wf_activity=0）、周辺設定件数、レコード件数。すべて PDI（Zurich / 2026-06-20 確認）の OOTB で取得しています。

• 確認していない範囲（断定しません）：各 Business Rule / Notification の内部スクリプトの挙動、Flow の中身。承認委任（sys_user_delegate）の動作、approval_history、Service Portal 上の承認 UI、本番でのカスタム承認フロー。これらは別記事で扱います。