見出し画像

ServiceNow サービスカタログ完全ガイド：申請フォーム1つが履行タスクに届くまで

ServiceNow観察日記


申請フォームを1つ追加してほしいと頼まれても、承認がどう回り履行タスクにどう届くのか掴みにくいことがあります。ServiceNowのサービスカタログでは、利用者がポータルでアイテムを選んで送信すると、裏側でRequest・RITM・Catalog Taskという3階層のレコードが生まれます。金額しきい値と部門長という2段階の承認を経て、履行タスクに届く仕組みです。Zurich PDIで、カタログアイテム198件の構成と、実際の注文が履行タスクに届くまでの流れを追いました。


検証環境：Zurich PDI / OOTB / 2026-08-09 確認

利用者が実際に開くのは、この注文フォームです。


価格・納期・数量に加えて、Optional Softwareのチェックボックスと自由記述の入力欄が並びます。この入力項目がカタログアイテムごとに定義された変数だという点が、この記事全体の骨格です。

利用者から見える流れ：カタログを開いてから完了通知まで

利用者にとってサービスカタログは、カタログを開いてアイテムを選び、フォームに入力して送信する、それだけの操作です。裏側で何が起きているかを1枚の図にすると、次のようになります。


先ほどのStandard Laptopのフォームで「Order Now」を押すと、画面には申請番号が表示され、そのまま「My Requests」の一覧に載ります。実際にこのPDIで発注されたREQ0010002(Standard Laptop)とREQ0010003(ソフトウェア利用申請)も、同じようにこの一覧から確認できます。


注文の中身は品目ごとにRequested Item(RITM)へ分かれ、RITM単位で部門長の承認を経ます。今回はRITM0010002とRITM0010003が承認を通過し、履行タスク(SCTASK0010001・SCTASK0010002・SCTASK0010003)が割り当てられました。SCTASK0010001はすでにClosed Completeまで進んでいます。一方でRITM0010001は部門長がRejectedを選んでおり、履行タスクは1つも作られていません。承認で止まった申請がどうなるかは、この1件が実例です。

結論：申請フォームは3層のレコードと2段階承認でできている

  • 利用者から見える操作は1つだけです。カタログでアイテムを選び、フォームに入力してOrder Nowを押すと、裏側でRequest・RITM(Requested Item)・Catalog Taskという3階層のレコードが自動的に作られます

  • 承認は2段階です。金額のしきい値を超えると1段階目の承認が入り、RITM単位の部門長承認が2段階目になります。どちらかで止まると、履行タスクは生成されません

  • 承認の記録はsource_tableの値で探し分ける必要があります。RITM起点の承認はsc_req_item、Request起点の金額しきい値承認はtaskという値で記録されるため、片方だけを検索すると承認そのものが無いように見えてしまいます

裏側の構造：カタログは何テーブルでできているか

ここからは、いま見た流れを支えるテーブル構造を1つずつ確認します。


起点はカタログアイテムです。そこから注文されるとRequestが生まれ、金額のしきい値を超えていれば1段階目の承認が動きます。Requestの中身は品目ごとにRequested Item(RITM)へ分かれ、RITM単位で2段階目の承認を経て、両方を通過すると履行タスクが生成される流れです。履行タスクは履行計画という雛形に従って作られます。

主要テーブルの規模を一覧にすると、次のとおりです。


作る側が用意するもの：カタログアイテムと変数

作る側の起点は明確です。利用者がカタログ画面で見る「申請ボタン」の1つ1つがsc_cat_item(カタログアイテム)です。今回のPDIには198件あり、公開中(active)は148件でした。所属先はsc_catalog(カタログ、2件)とsc_category(カテゴリ、45件)で、カテゴリごとに一覧の並びが決まります。


アイテムに入力項目を持たせるのが変数(item_option_new)です。今回は638件ありました。種類(type)の上位5つはSingle Line Text 109・Select Box 95・CheckBox 71・Multi Line Text 64・Reference 63です。上位5種だけで638件中402件、63%を占めています。凝った入力形式よりも、シンプルな文字入力・選択・参照が大半を占める構成でした。


同じ入力項目を複数のアイテムで使い回す仕組みが変数セット(item_option_new_set、24件)です。アイテムと変数セットは直接つながらず、io_set_itemという中間表を介して多対多で結びつきます。この結びつき方の詳細は、同じ入力項目を9アイテムで使い回す中間表(io_set_item)で扱っています。

入力項目が用意できたら、次に決めるのは「いつ・どの項目を表示するか」です。この制御を持つのはcatalog_ui_policy(102件)とcatalog_script_client(127件)でした。いずれも通常フォーム用のsys_ui_policyやsys_script_clientを、さらに継承した専用テーブルです。仕組みの違いは注文フォームの制御は通常フォームと別テーブル(catalog_ui_policy)にまとめています。

Record Producer(sc_cat_item_producer、40件)という選択肢もあります。カタログ画面と同じ見た目でありながら、RITMを作らずincidentなど指定したテーブルへ直接レコードを作る入口です。Record Producer は RITM を作らないで継承関係を確認しています。

履行の準備も作る側の仕事です。品目が承認を通過したあと「どんな作業を、どの順番で、どのグループに出すか」を決めておく雛形が履行計画(Execution Plan、sc_cat_item_delivery_plan)です。今回のPDIには15件あり、配下のタスク雛形(sc_cat_item_delivery_task)は53件でした。


雛形と、注文のたびに生成される実レコード(sc_task)は別テーブルです。雛形1件から複数のタスクが実行順(order)付きで作られる仕組みは、Catalog Task はどこから来るか(履行計画)で確認しています。複数アイテムを1つの申請にまとめて頼む仕組み(オーダーガイド)は複数アイテムを1申請に束ねる(オーダーガイド)が扱っています。実際に1アイテムを土台から履行タスクが動くところまで組み立てた手順はゼロから作る手順：申請フォームが動くまでにまとめました。

承認はどこで生まれるか：金額しきい値と部門長の2段階

承認の記録先は1つのテーブルに集まります。サービスカタログの承認はsysapproval_approverというテーブルに記録されますが、このテーブルはカタログ専用ではありません。Changeなどほかのプロセスの承認も同じ場所に記録される、共通の承認基盤です。

カタログ発の承認は2段階に分かれています。1段階目は金額のしきい値による承認、2段階目はRITM単位の部門長承認です。


承認を通過したRITM0010002からは、履行タスクがSCTASK0010001とSCTASK0010002の2件生成されました。SCTASK0010001はすでにClosed Completeまで進んでいます。RITM0010003からもSCTASK0010003が1件生成されています。一方でRITM0010001はRejectedのままで、履行タスクは1つも作られていません。

承認の探し方には注意が必要です。RITM単位の承認はsource_table=sc_req_itemで見つかります。Request段階の金額しきい値承認は、source_table=taskという値(taskテーブルの汎用値)で記録される点に注意してください。source_table=sc_requestで検索すると0件のままで、承認そのものが存在しないように見えてしまいます。

実機で気づいたこと

承認レコードを絞り込むとき、素直にsource_table=sc_requestで検索しても該当は出てきません。最初は「Requestに対する金額しきい値の承認はこの環境に無いのか」と思いました。実際にはsysapproval_approverのsource_tableに"task"(taskテーブルの汎用値)が入っていました。RITM単位の部門長承認はsource_table=sc_req_itemで正しく引けます。同じ2段階の承認でも、段によって記録のされ方が違う点は実機を追わないと気づけませんでした。棚卸しや監査でカタログの承認漏れを調べるときは、sc_req_itemだけでなくtaskも合わせて見る必要があります。

承認レコードが1件も無いRITMもありました。意外でした。たとえばOOTBのシードデータであるRITM0000001には、承認レコードが1件も存在しません。承認が付くかどうかはしきい値や品目側の設定(ワークフロー・フローの有無)に左右され、承認そのものが発生しないルートもあると分かりました。

履行計画の厚みにも驚きました。15件の計画に53件のタスク雛形が用意されている一方、実際にこのPDIで使われた履行計画はごく一部でした。OOTBのテンプレートは幅広い用途を見込んで作り込まれているのに対し、実際に動いた履行はその一部にとどまります。テンプレートの多さをそのまま「よく使われている機能」と読み替えるのは早計だと分かります。

変数の型でも偏りがありました。638件のうち上位5種(Single Line Text・Select Box・CheckBox・Multi Line Text・Reference)で63%を占めています。List CollectorやLookup Select Boxのような凝った入力形式は用意されているものの、実際の変数定義の大半は基本的な文字入力・選択・参照で足りていました。

sc_taskの番号にも、新旧2つの体系が混ざっていました。RITM0010002とRITM0010003から生成されたタスクはSCTASKという番号でしたが、OOTBのRITM0000001から生成されたタスクはTASK0000001という古い番号のままです。番号の先頭がSCTASKかTASKかを見るだけで、そのレコードが後から追加されたテストデータか、最初から入っていたOOTBのシードデータかを見分ける手がかりになると気づきました。

どこで詰まったらどれを読むか

11本の子記事は、作る側・動かす側・運用する側の3つに束ねると探しやすくなります。

作る側(カタログアイテムを組み立てるとき)は、次の6本です。「変数をどう再利用すればいいか」「入力に応じて項目を出し分けたい」という段階で読む記事群です。

動かす側(申請すると何が起きるかを追うとき)は、次の2本です。「RITM番号で検索したのに見つからない」「承認したのに履行タスクが出てこない」というときに読みます。

運用する側(現場の運用・棚卸しをするとき)は、次の3本です。いずれも有料で、運用ルールを決める・見直す立場で読む記事群です。


つまずきやすい点

  • source_table=sc_requestで承認を検索しても0件です。Request起点の承認はsource_table=taskに記録されるため、両方を確認する必要があります

  • sc_req_itemのstate内部値はtaskテーブル共通の選択肢(-5=Pending、1=Open、2=Work in Progress、3=Closed Complete、4=Closed Incomplete、7=Closed Skipped)を継承しています。sc_req_item固有の上書きはありませんでした

  • 履行計画(delivery_plan)が設定されていても、その品目が一度も注文されなければsc_taskは1件も生まれません。雛形の件数だけで運用の稼働状況を判断できません

  • 変数の入力項目を決める属性(name・question_text・type・mandatory)は親のquestionテーブル側にあり、item_option_new自体は持ちません

  • カタログ用のUI Policy/Client Scriptは、通常フォーム用のテーブルをもう一段継承した別テーブルです。同じ名前の機能でも保存先が違います

よくある質問

Q1. カタログアイテムを1つ追加したいとき、最初に何を作ればいいですか

sc_cat_itemの本体を作り、次に入力項目(変数)を追加します。複数アイテムで使い回す項目があれば変数セットにまとめ、表示制御が必要ならCatalog UI Policyを設定します。手を動かす順番はゼロから作る手順で番号付きに整理しました。

Q2. 承認が2段階あるのに、片方しか見つからないのはなぜですか

source_tableの値がRequest起点とRITM起点で違うためです。RITM起点の承認はsource_table=sc_req_itemで見つかりますが、Request起点の金額しきい値承認はsource_table=taskに記録されます。両方を確認しないと、片方の承認だけを見落とします。

Q3. 承認したのに履行タスクが生成されません

今回の実測でも、2段階のうち後段(部門長承認)まで通らないと履行タスクは作られませんでした。RITM0010001はこのパターンに当てはまり、Rejectedのまま履行タスクは1つも生成されていません。1段階目だけを承認して安心してしまうと、2段階目の承認が誰にも気づかれないまま止まります。運用での見落としやすさはサービスカタログ運用手順書で扱っています。

Q4. オーダーガイドと通常のカタログアイテムは何が違いますか

オーダーガイドはカタログアイテムを継承した「特殊なアイテム」で、含めるアイテムを別テーブルのルールで動的に出し分けます。1回の申請で複数アイテムをまとめたいときに使う仕組みで、詳しくは複数アイテムを1申請に束ねる(オーダーガイド)で扱っています。

Q5. 公開しているカタログアイテムが実際に使われているか確認する方法はありますか

sc_req_itemのcat_itemを集計すると、どのアイテムが何件注文されたか分かります。今回のPDIでは198件のうちごく一部しか注文されていませんでした。自分の環境で同じ棚卸しをする手順とスクリプトは誰も頼んでいないカタログを洗い出す手順にまとめています。

まとめ

地図はシンプルです。サービスカタログは、カタログアイテムと変数という「作る側」の土台の上に、注文されるたびにRequest・RITM・Catalog Taskという3階層のレコードが生まれる仕組みです。承認は金額しきい値とRITM単位の部門長承認という2段階に分かれ、記録されるsource_tableの値がそれぞれ違う点が、実機を追って初めて分かった発見でした。

履行計画は15件・タスク雛形53件という厚みを持つ一方、実際に動いた履行はテンプレートのごく一部です。用意されている仕組みと、実際に動いている範囲には差があります。全体の地図が掴めたら、あとは自分がいま「作る側」「動かす側」「運用する側」のどこで困っているかに応じて、子記事を選んで読み進めてください。

用語

  • sc_cat_item(カタログアイテム) … 利用者が申請できる品目の定義

  • item_option_new(変数) … カタログアイテムやRecord Producerの入力項目の定義

  • sc_request(Request) … 1回の申請のまとまり。番号はREQ

  • sc_req_item(Requested Item / RITM) … 申請された品目ひとつ。承認・履行の単位

  • sc_task(Catalog Task) … 品目を満たすための作業。番号はSCTASK

  • sc_cat_item_delivery_plan(履行計画 / Execution Plan) … 履行タスクの雛形を持つ計画本体

  • sysapproval_approver … 承認者1人につき1件記録される承認レコード

実機で確認したURL

  • /sc_cat_item_list.do?sysparm_query=active%3Dtrue%5EORDERBYname … 公開中のカタログアイテム一覧

  • /sc_category_list.do?sysparm_query=GROUPBYactive … カテゴリのactive別件数

  • /item_option_new_list.do?sysparm_query=GROUPBYtype … 変数の型別件数

  • /catalog_ui_policy_list.do … Catalog UI Policyの一覧

  • /sc_cat_item_delivery_plan_list.do … 履行計画の一覧

  • /sc_req_item_list.do?sysparm_query=GROUPBYcat_item … RITMのカタログアイテム別件数

  • /sc_req_item_list.do?sysparm_query=GROUPBYstate … RITMのstate別件数

  • /sc_task_list.do?sysparm_query=GROUPBYstate … Catalog Taskのstate別件数

  • /sysapproval_approver_list.do?sysparm_query=source_table%3Dsc_req_item … RITM起点の承認一覧

参考リンク

検証環境と未検証範囲

件数・画面はZurich PDI(OOTB)で確認したものです。一覧画面の表示件数と集計を突き合わせて数えており、推定やサンプリングではありません。子記事とは検証日が異なるため件数がわずかに前後しますが、本記事は今回の実測値を採用しています。REQ0010001〜0010003・RITM0010001〜0010003・SCTASK0010001〜0010003は、本記事のために新規作成した記録ではありません。このPDIに元々あった申請記録です。

未読の範囲もあります。承認ワークフローやフロー(Flow Designer)のスクリプトの中身、通知(Notification)の送信条件までは読んでいません。承認基盤全体のうち大部分はchange_request由来で、その内訳は別記事(変更管理完全ガイド)の担当範囲です。承認レコードが無いRITMがあった理由(しきい値未満なのか、品目側でワークフローが未設定なのか)は、対象品目の設定を1つずつ開いて確認する範囲までは踏み込んでいません。本番環境やカスタマイズ済みの環境では、テーブル構成・件数・承認ルートが変わります。数字は環境ごとに違っても、カタログアイテムが3階層を生み、2段階の承認を経て履行タスクに届くという構造そのものは共通です。

いいなと思ったら応援しよう！