承認は2段構え：1段目だけでは履行が始まらない（RITM/Catalog Task）

ServiceNow（サービスナウ）の Service Catalog で Standard Laptop（$1,100）を実際に2件注文しました。Request・Requested Item（RITM）・承認レコード・Catalog Task がどう生成され、どこまで進むかを追いました。1件目（REQ0010001）は承認の途中で止まりました。2件目（REQ0010002）で承認2件を両方通し、Catalog Task の生成からRITMのstageが"Deployment"に進むところまで確認できました。

この記事で分かること

• 注文用のAPIで実際に1件申請すると、Request と Requested Item に何が書き込まれるか

• 承認が2段階に分かれていて、1段階目を承認しただけでは履行が始まらないという、実際につまずいた記録

• 2段階の承認を両方通したときに、Catalog Task（sc_task）がいつ・どんな内容で生成されるか

• Catalog Task を完了させると Requested Item がどこまで進むか

• 申請の各段階で送信されたメールと、送信されなかった通知の実測

• 承認や履行を裏で支えているビジネスルール・スクリプトの件数と代表例

注文したカタログアイテムと使ったAPI

品目の定義（価格・変数）

今回申請したのは Standard Laptop（sc_cat_item）です。価格は一括 $1,100、加えて年額 $100 の recurring_price が定義されていました。

Standard Laptop は category が Hardware、所属カタログは Service Catalog（もう1つの Technical Catalog とは別）でした。品目には一括の price だけでなく年額の recurring_price も定義されており、注文後に生成された RITM側にもそのまま $100 が複写されていました。継続コストを持つ品目でも、注文そのものは1件のRITMとして生成されます。

品目やカタログの位置づけそのものは、公式ドキュメントに説明があります。本記事では、この品目を実際に2件注文した結果を追います。

注文に使ったAPI

注文には Service Catalog Ordering API を使いました。

POST /api/sn_sc/servicecatalog/items/04b7e94b4f7b4200086eeed18110c7fd/order_now

このAPIは Table API で sc_request に直接 INSERT する方法とは違います。利用者がカタログ画面で「注文」ボタンを押したときと同じ処理経路を通り、価格の再計算・変数の検証・承認判定・RITMの生成までを、注文導線に沿って一括で実行します。同じエンドポイントに2回リクエストを送り、1件目をREQ0010001、2件目をREQ0010002として追いました。

変数の定義と回答値の保存先

Standard Laptop に定義された変数（item_option_new）を確認すると、次が並んでいました。

• 見出し用のラベル「Optional Software」

• チェックボックスの「Adobe Acrobat」「Adobe Photoshop」

• 自由記述の「Additional software requirements」（複数行テキスト）

4件とも mandatory は false で、必須の変数はありません。

1件目の注文はAPI経由で変数を指定せずに送ったため、生成された回答値（sc_item_option）を見ると、チェックボックス2件はどちらも false、複数行テキストは空のままでした。ラベル分も含めて4件の sc_item_option が生成され、sc_item_option_mtom を介して RITM0010001 に紐づいています。変数を選ばなくても、定義された数だけ回答値のレコードが作られることが、この1件から確認できます。「Optional Software」の行は、フォーム上で入力項目を束ねる見出しです。利用者が値を選ぶ対象ではありません。それでも他の変数と同じように、回答値のレコードが1件生成されていました。

承認理由の文言は「Request Total Price is more than $1000.」で、Requestのpriceフィールド（$1,100）を根拠にしています。年額のrecurring_price（$100）がこのしきい値判定に含まれているかどうかは、フロー内部のロジックまでは確認していません。

変数の定義（item_option_new）と、申請後の回答値（sc_item_option）が別テーブルに分かれている点は、公式ドキュメントにも解説があります。

生成された Request と Requested Item の実データ（1回目の注文）

1件目の注文の結果、Request が1件、Requested Item（RITM）が1件生成されました。

Request（REQ0010001）側

Request 全体を見ると、次の値でした。

Requested Item（RITM0010001）側

一方、品目単位のRITMを見ると、次のとおりでした。

due_date が注文から9日後に設定されている点も確認できました。この日数が品目側の標準リードタイム設定によるものかどうかは、今回は追っていません。

Request側の approval は Approved なのに、RITM側の approval は Requested のままでした。同じ注文の Request と RITM で、承認を表すフィールドの値が食い違って見えます。これは単なる表示の更新ラグではありません。次の章で分かるとおり、RITM側に独立した承認ステップが実際に生きているためでした。

承認は2段階、別々のレコードで動いていた

承認待ち一覧（sysapproval_approver_list.do）を確認すると、1件目の注文からは性格の違う2件の承認レコードが生成されていました。

この2段階の承認から、2回目の注文（REQ0010002）でCatalog Taskの生成・完了まで進めた結果までを追いました。節目ごとに時系列で並べたのが次の表です（RITM0010002・SCTASK0010001の詳細は後述します）。

作成日時をそのまま並べると、順序がはっきりします。

• 05:43:03 … 注文の実行

• 05:43:09 … Request宛ての承認レコードが生成（6秒後）

• 05:47:31 … その承認が Approved に（4分28秒後）

• 05:47:36 … RITM宛ての承認レコードが生成（さらに5秒後）

金額しきい値の承認が確定した直後に、次の承認が生成されます。この順序が秒単位の記録からそのまま追えます。

1段階目：Request 全体を対象にした、金額しきい値の承認

1件目は document_id が REQ0010001 を指す承認レコードでした。承認者は Eric Schroeder、approval_reason は「Request Total Price is more than $1000.」です。state は Approved で、注文から4分半ほどで承認済みになっています。

この承認レコードを束ねる sysapproval_group（番号 GAPRV0010008）を見ると、次のとおりでした。

• parent：REQ0010001

• approval_user：Eric Schroeder

• wait_for：Process Flow

Eric Schroeder がどの立場で承認者に選ばれたかを sys_user_grmember で確認しました。「Catalog Request Approvers > $1000」という名前のグループの、唯一のメンバーであることが分かりました。つまりこのグループは実質1人構成です。Request の合計金額が $1,000 を超えたことをきっかけに、このグループ宛てに承認が生成されたとみられます。

2段階目：Requested Item を対象にした、部門長の承認

2件目は document_id が RITM0010001 を指す承認レコードで、承認者は Natasha Ingram、state は Requested（承認待ち）のままでした。作成時刻は、1段階目の承認が Approved になった5秒後です。

1段階目の承認が完了した時点で、履行のための Catalog Task（sc_task）がまもなく生成されるものと考え、10分ほど画面を放置しました。ところが sc_task には何も生成されていません。承認一覧を確認し直してはじめて、RITM0010001宛ての2件目の承認レコードがまだ Requested のまま残っていることに気づきました。Request側の承認が終わっても、RITM側の承認が残っている限り履行は始まりません。承認フィールドが一部だけ Approved になった状態を見て、申請全体が片付いたと判断するのは早計でした。

Natasha Ingram がなぜ選ばれたのかを追うと、申請者（admin ユーザー）は manager フィールドが空でしたが、department は Finance でした。Finance 部門のレコード（cmn_department）を見ると、dept_head（Department head）フィールドが Natasha Ingram と一致しました。

RITM側の"Dept. Head Approval"ステージの承認者は、申請者のmanagerではなく、申請者が所属する部門のdept_headから解決されていました。manager が未設定でも承認者が決まっていたのは、この部門長の経路が働いたためとみられます。

2つの承認は、判断の対象が違います。Request側は申請全体の合計金額を見て、しきい値を超えたかどうかで承認者を決める仕組みでした。RITM側は品目1件ごとに、申請者の所属先を見て承認者を決めていました。合計額を見る承認と、品目単位で人を決める承認とでは、見ている単位がそもそも異なります。

しきい値未満の注文との比較

金額しきい値が働いていることは、比較でも裏づけられました。同じPDIには、初期データとして入っていた $600 の Request（REQ0000001）がもう1件だけありました。こちらには sysapproval_approver が1件も存在しませんでした。$1,000 を超えた今回の注文だけに、しきい値グループ宛ての承認が発生していたことになります。

一方でこの $600 の Request 配下には RITM が5件ありました。price $600 の1件（RITM0000001）はすでに stage が Fulfillment、approval が Approved まで進んでいました。残り4件は request_approved や、価格 $0 のまま stage が "Dept. Head Approval" のものもありました。金額のしきい値と無関係に、品目ごとにこの承認ステップが発生しうることを示しています。すべての品目・すべての申請者で必ず発生するとまでは確認できていません。

RITM0010001 自体は、2段階目の承認が保留のままだったため、履行以降には進んでいません。この先の動きは、2件目に注文したRequestで最後まで追いました。

2回目の注文で、Catalog Task から Deployment まで追う

2件目の注文（REQ0010002）は、同じ Standard Laptop を同じ order_now エンドポイントで申請したものです。今回は1件目で見つかった2段階の承認を両方とも承認まで進め、Catalog Task の生成から先を確認しました。

承認2件を両方とも承認する

REQ0010002側の承認レコードは、1件目と同じ仕組みでした。承認者は Eric Schroeder、approval_reason は「Request Total Price is more than $1000.」です。承認レコードが生成されてから約3.5分後、かつこの承認を承認した2秒後に、RITM0010002 宛ての承認レコードが自動生成されました。承認者はここでも Natasha Ingram で、申請者の department（Finance）から dept_head を解決する経路は1件目と同じです。

1件目ではこの2件目の承認をRequestedのまま放置していましたが、今回は承認しました。

Catalog Task が生成される

Request側・RITM側の承認が両方Approvedになった直後、sc_task テーブルにレコードが1件生成されました。番号は SCTASK0010001 でした。short_description は「Please fulfill this order」、assignment_group は Procurement でした。承認が2段階とも揃うまで、Catalog Taskは生成されません。1件目の注文でCatalog Taskが現れなかったのは、この条件が満たされていなかったためだったことになります。

Catalog Task が担当する履行の実務は、公式ドキュメントにも説明があります。assignment_group が Procurement になっていた点は、この記事の解説とも整合します。

Catalog Task を完了させると、RITM は Deployment へ進む

SCTASK0010001 を Closed Complete にすると、RITM0010002 の stage が Deployment に進みました。

今回の検証はここまでです。RITM0010002自体がこの先 Closed Complete まで進むかどうかは確認していません。Deployment のあとにもう1段階以上のstageが残っている可能性があります。

送信されたメールと、送信されなかった通知

注文から Catalog Task の完了までの間に、sys_email テーブルに記録されたメール送信は次の4件でした。

発生タイミング              宛先                     件名
Request作成直後             申請者(admin)            Request REQ0010002 was created
第1段階承認の依頼発生時      Eric Schroeder            Request REQ0010002 needs your approval
第1段階承認完了時            申請者(admin)            Request  REQ0010002 was approved
Catalog Task完了直後         申請者(admin)            Your requested item RITM0010002 for Standard Laptop is in stock and will be deployed soon!

一方で、第2段階（部門長承認、Natasha Ingram宛）の承認依頼が発生したときには、メールが送信されていませんでした。sys_email にはそれらしいレコードがなく、sysevent_email_action を見ると通知の定義自体は存在するのに、この経路では発火していません。承認者は、承認一覧の画面を自分で確認しにいかない限り、依頼が来たことに気づけないことになります。

Catalog Task が Procurement グループにアサインされた際の"assigned to group"通知も、同じように定義は存在するものの、実際には送信されていませんでした。通知の定義があることと、実際に送られることは別だと分かります。通知の設定方法自体は、公式ドキュメントにまとまっています。

周辺で動いていたビジネスルールとスクリプト

承認や履行のレコードが自動で書き換わる裏では、複数のビジネスルールが動いていました。active なビジネスルールの件数は次のとおりです。

• sc_request：10件

• sc_req_item：20件

• sc_task：13件

• sysapproval_approver：14件

代表的な名前としては、sc_req_item の"request item closure"（RITMのクローズ処理）や"Close Parent if Required"が見つかりました。sysapproval_approver では"Approval Events (Task)"・"Approval Events (Non-Task)"（承認完了時のイベント発火。メール通知のトリガーになっているとみられる）が見つかりました。個々のスクリプト内容までは確認していません。

Script Include の一覧には "CatalogTaskGenerator" という名前もありました。Catalog Task の生成に関わっているとみられますが、内部処理の詳細は確認範囲に含めていません。ビジネスルールの基本的な仕組みは、公式ドキュメントに解説があります。

使われているFlowと全体の規模感

Flow Designer で動いていた

今回の申請を処理していたのは、Flow Designer のフロー Service Catalog item request（レガシーWorkflowではなくFlow）でした。このフローが持つアクション数を数えると5件でした。各アクションの具体的な設定内容までは今回確認していません。従来のOOTBでは、同じような2段階の承認をレガシーWorkflowのテンプレートで組んでいる構成もありますが、その内部までは本記事の確認範囲に含めていません。Flow から承認を発行する仕組み、承認テーブルの選び方は、公式ドキュメントにまとまっています。

カタログ全体の規模

カタログ全体の規模も確認しました。カタログアイテム（sc_cat_item）は196件で、うち active な品目は146件です。内訳は次のとおりです。

• Record Producer（sc_cat_item_producer）：39件

• カタログ（sc_catalog）：2つ（Service Catalog / Technical Catalog）

• 有効なカテゴリ：20件

Standard Laptop が属する Hardware カテゴリだけでも17件の品目があり、今回の2件はその中の1品目にすぎません。

実機から分かったこと

• 注文用のAPIで1件申請すると、Request 1件・RITM 1件が生成され、それぞれ別に承認フィールドを持つ。両者の値は同時には揃わない。

• 変数を1つも選ばなくても、定義された数だけ回答値（sc_item_option）のレコードが作られる。定義と回答は別テーブル。

• 承認は Request 全体を対象にした金額しきい値のものと、RITM 単位の部門長のものとで、別レコード・別タイミングで生成される。1段階目だけ承認しても、2段階目が残っていれば履行は始まらない。

• 金額しきい値の承認グループは、実データでは1人構成だった。グループという名前でも、必ずしも複数人とは限らない。

• 部門長承認は、申請者の manager ではなく、所属部門の dept_head から解決されていた。

• 2段階の承認が両方Approvedになると sc_task に Catalog Task が生成される。Closed Complete にすると RITM の stage が Deployment に進む。

• 申請の節目ごとにメールが送られる一方、部門長承認の依頼発生時とCatalog Taskのグループアサイン時は、通知定義があっても実際には送信されていなかった。

承認フィールドの値だけを見て、申請が終わったと判断するのは早計です。1段階目が承認された直後に何も起きないからといって、システムが止まっているとは限りません。2段階目の承認レコードが残っているかどうかを、承認一覧で確認する必要があります。

次に読むなら

Request / Requested Item / Catalog Task の役割を構造から確認したい場合や、承認レコードの生成元・集計ルールを詳しく知りたい場合は、次の記事を読んでください。これら3本はいずれもテーブル定義から構造を読み解く記事です。今回のように1件の注文をCatalog Task・Deploymentまで追った記事とは視点が異なります。あわせて読むと、定義として存在する構造と、実際に注文したときに生成される値の両方が見えてきます。

用語

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

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

• RITM：Requested Item（sc_req_item）。申請された品目ひとつ

• order_now：Service Catalog Ordering API のエンドポイントの1つ。カタログ画面の「注文」と同じ処理経路で1件を注文する

• dept_head：cmn_department（部門）に定義された部門長を指す参照フィールド

• item_option_new：品目に定義された変数（入力項目）そのもの。申請ごとの回答値ではない

• sc_item_option：申請1件ごとの変数の回答値。item_option_new とは別テーブルで、sc_item_option_mtom を介してRITMに紐づく

• sysapproval_group：複数の承認者を束ねて1つの結果にまとめる、承認レコードの親

• recurring_price：品目に定義された継続課金額。今回は年額$100で、RITM側にもそのまま複写される

• sc_task：Catalog Task。RITM配下で履行の実務を担当グループに割り当てるタスク

• Deployment：RITMのstageの1つ。Catalog TaskがClosed Completeになったあとに進む段階

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

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

注文API           : POST /api/sn_sc/servicecatalog/items/{sys_id}/order_now
RITM フォーム      : sc_req_item.do?sys_id=<RITMのsys_id>
Request フォーム   : sc_request.do?sys_id=<Requestのsys_id>
承認一覧           : sysapproval_approver_list.do
承認グループ フォーム: sysapproval_group.do?sys_id=<グループのsys_id>
Catalog Task フォーム: sc_task.do?sys_id=<Catalog Taskのsys_id>
カタログアイテム フォーム: sc_cat_item.do?sys_id=<品目のsys_id>
部門 フォーム       : cmn_department.do?sys_id=<部門のsys_id>
送信メール一覧      : sys_email_list.do

検証範囲とおことわり

• 確認した範囲：Standard Laptop の注文APIによる申請2件、生成された Request・RITMの実データ

• 品目に定義された変数と回答値の中身、Request側とRITM側それぞれの承認レコードの内容

• 金額しきい値グループの実メンバー構成、部門長承認の解決経路、しきい値未満の注文との比較

• 2件目の注文で2段階の承認を両方通した結果生成されたCatalog Task（SCTASK0010001）の内容

• Catalog Task を Closed Complete にしたあとの RITM stage の変化（Deployment）

• 送信されたメール（sys_email）の実測と送信されなかった通知の実測

• 周辺のビジネスルール件数、使用Flowの種別とアクション数、カタログ全体の規模。すべてPDI（Zurich / 2026-07-04 確認）のOOTBで取得しています

• 確認していない範囲（断定しません）：Flow内の各アクションの詳細な設定、部門長承認がすべての品目・申請者で発生するかどうかの一般化

• RITM自体が最終的にClosed Completeまで進むかどうか、Deploymentの先にさらにstageが残っているかどうか

• 承認が却下された場合の動き、他の価格帯や他ユーザーでの再現性、recurring_priceがしきい値判定に含まれるかどうか

• ビジネスルールやScript Include（CatalogTaskGenerator等）の内部ロジック。これらは、別ユーザーで再度注文したうえで、別記事にする予定です