ServiceNowのポータルの「自分の申請」には何が出る？ 5テーブル42件の定義を実機で読む

「申請したはずなのに一覧に出てこない」。利用者からこの問い合わせを受けると、どこを見ればよいか迷います。ポータルの申請一覧は、何を出すか・どう絞るかが5つのテーブルに分けて定義されていました。しかも標準のフィルタ機構の上に乗っています。仕組みを押さえたうえで、素の環境の中身を読みました。

申請一覧に本来何が見えてほしいか

まず利用者が見る画面を出します。Employee Center の Requests です。

For you / For others / Drafts の3つがタブとして並び、その下に「Filter by: Status」があります。カードには番号・状態・申請対象者・経過時間が出ています。

この見た目が、これから読む5テーブルの設定で決まっています。タブがどこから来るのか、Status に何が出るのか、カードに誰の名前が出るのか。画面と定義を突き合わせながら追います。

利用者がポータルで「自分の申請」を開くとき、期待しているのは3つです。

自分が関わったものが漏れなく出ること。 出すぎないこと。そしてまだ終わっていないものがすぐ分かること。

管理者の側から見ると、これを満たすには3つを決める必要があります。一覧に載せるテーブル。「自分の」の判定方法。用意する絞り込み。ServiceNow はこの3つを、それぞれ別のテーブルに持たせていました。

この仕組みの位置づけ

ポータルの一覧というと、リストビューやレポートを思い浮かべるかもしれません。この仕組みはそのどちらとも違います。

リストビューが表示するのは1つのテーブルです。ここでは複数のテーブルを1つの一覧にまとめて出します。カタログ申請もインシデントも同じ画面に並びます。

そしてフィルタの定義そのものは標準の仕組みを流用していました。テーブルの継承元を見ると、一覧に出すテーブルの指定と、絞り込みの実条件が、どちらも Filter（sys_filter）を継承しています。

sys_filter はリストやホームページで使うフィルタを保存する、以前からあるテーブルです。公式の説明にも「Roles that can use this filter on a list or homepage」とあります。ポータルの申請一覧は、その仕組みの上に新しい層を足した作りでした。

5つのテーブルはすべてスコープが Employee Center でした。プラットフォーム共通の仕組みではありません。Employee Center というアプリケーションが持ち込んだものです。既定ポータルの構成は既定ポータル Employee Center（/esc）はカタログを持たないで扱いました。

5つのテーブルは何を分担しているか

役割で分けると分かりやすくなります。

何を出すかを決めるのが sn_ex_sp_request_source（画面上の名前は Source configurations）。一覧に載せるテーブルと、見出しに使う列を持ちます。

どんな絞り込みを用意するかが sn_ex_sp_request_filter_definition（Filter definitions）。絞り込みの種類を定義します。

その選択肢が sn_ex_sp_request_filter_config（Request filter configuration）。「開いているもの」「閉じたもの」といった具体的な選択肢です。

実際のクエリが sn_ex_sp_request_filter_conditions（Request filter conditions）。選択肢とテーブルの組み合わせごとに、絞り込み条件を持ちます。

タブとの組み合わせが sn_ex_sp_request_tab_filter_mtom（Request tab filter）です。

この分け方の利点は、片方だけ触れることです。新しいテーブルを一覧に足すならソースに1行。選択肢を増やすなら設定と条件に足す。変える頻度も、変える人も違うものが分かれています。

公式が書いている重要な制約

絞り込みの定義には render_as_view という項目があります。公式の説明を引くと、この仕組みの見え方がはっきりします。

説明は2文に分かれていました。

「When selected, the filter configurations will be displayed as tabs.」

「Only one view configuration is allowed per portal.」

前半は、この項目を選ぶと絞り込みがタブとして表示されるという意味です。後半が重要で、1つのポータルにつきタブ表示にできる定義は1つだけという制約が明記されています。

つまりタブは1系統しか作れません。「自分の／他人の」と「未完了／完了」を両方タブにする設計は取れないということです。片方はタブ、もう片方は通常の絞り込みにします。

filter_type の説明は「Choice of filter type」で、絞り込みの型を選ぶ項目だと分かります。

設計上の制約が公式のフィールド説明に書かれているので、要件を詰める前に読んでおく価値があります。

結論：「自分の申請」の判定はテーブルごとに違う

一覧に出るテーブルは4つでした。カタログ申請、申請の明細、インシデント、業務アプリ申請です。

絞り込みは3種類。タブとして描かれる View Filter、複数選択できる Status、期間で絞る Updated。

そして重要な点がひとつ。「自分の申請」を判定する列が、テーブルごとに違います。 インシデントは報告者、申請明細は申請対象者、業務アプリ申請は担当者。同じ「自分の」でも見ている列が別です。

一覧に出るのは4テーブル

まず何が表示対象なのかを見ます。sn_ex_sp_request_source に4件のレコードがありました。

4件とも active は true。all_portals も true でした。特定のポータルに限定せず、どこでも有効という設定です。ポータルを複数持つ環境でも、同じ4テーブルが出ることになります。

見出しに使う列が1件だけ違う

title_field を見ると、sc_request だけ number を使っています。他の3件は short_description でした。

理由は中身の違いでしょう。カタログ申請（sc_request）は「申請の入れ物」なので、それ自体に短い説明がありません。REQ番号を出すしかない。一方で明細やインシデントには、何を頼んだか・何が起きたかの説明が入ります。

申請が3テーブルに分かれる構造そのものはServiceNowの申請1件はなぜ3テーブルに分かれる？で扱いました。この分かれ方が、一覧の見せ方にも影響しています。

遷移先のページが3種類ある

portal_page に注目すると、3種類ありました。order_status、ticket、standard_ticket です。

カタログ申請だけ order_status に飛びます。注文の進み具合を見せる専用ページです。インシデントと申請明細は共通の ticket ページ。業務アプリ申請は standard_ticket でした。

行を押した先が同じ画面ではありません。一覧は1つでも、詳細画面は種類ごとに分かれています。 ポータルのページ構成はServiceNowのポータル画面1枚は何でできている？で追いました。

絞り込みは3種類

sn_ex_sp_request_filter_definition に3件あります。

View Filter が order 100。Status が 200 で、Updated が 300 でした。この数字で画面に並ぶ順番が決まります。値が100刻みなので、あいだに独自のフィルタを挿し込む余地があります。

View Filter だけタブとして描かれる

3件の違いを見ると、フィールドの値がきれいに分かれていました。

render_as_view が true なのは View Filter だけ。この値が「タブとして表示する」という指定だと読めます。

is_multiselect が true なのは Status だけでした。開いているものと閉じたものを同時に見たい場面があるので、複数選択を許しています。

Updated はどちらも false。期間は1つだけ選ぶ、タブにはしない、という扱いです。

3件それぞれが別の性格を持っていて、値の組み合わせでそれを表現しています。フラグを2つ持たせるだけで3種類の見せ方を作れる構成です。

選択肢は7件、うち1件は無効

sn_ex_sp_request_filter_config に7件のレコードがありました。各フィルタが持つ選択肢です。

View Filter が For you / For others / Other の3つ。Status が Open / Closed の2つ。Updated が Last 7 days / Last 30 days の2つ。

ここで目に付くのが Other です。7件のうちこれだけ active が false でした。定義は入っているのに、画面には出ません。

Other が無効な理由を考える

For you（自分の）と For others（他人の）があって、その次が Other。名前からすると、どちらでもないものを指す枠でしょう。

実際に条件を書こうとすると難しいところです。自分でも他人でもない申請とは何か。定義しきれなかったから無効のまま残した、と読むのが自然に見えます。

order は300が振られているので、有効化すれば3番目のタブとして出ます。将来使う余地を残した形です。

紐付けのテーブルにも Other の行が2件ありました。有効にした瞬間、Status と Updated が使える状態で表示されます。準備だけ済ませてスイッチを切ってある、という状態です。

この形は独自のタブを足すときの手本になります。選択肢を1件足し、条件を書き、紐付けを作る。3か所を触れば新しいタブが増えます。

apply_on_load は7件とも false

もうひとつ気づいた点があります。apply_on_load が7件とも false でした。

画面を開いた直後は、どのフィルタも適用されません。全件が出た状態から、利用者が絞り込む流れになります。

件数が多い環境では最初の表示が重くなる設計です。既定で Open を適用しておけば軽くなりますが、そうしていません。「まず全部見せる」を選んだのだと考えられます。

実際のクエリは22件

ここが一番面白い。sn_ex_sp_request_filter_conditions に22件ありました。

テーブル別に数えると sc_request 6件 / incident 6件 / sc_req_item 5件 / business_app_request 5件。合計22件でした。

選択肢は7件あるのに、テーブルごとの条件は5件か6件。全部の選択肢が全部のテーブルに用意されているわけではありません。

「自分の」の意味がテーブルごとに違う

For you の条件を並べると、見ている列が全部違いました。

インシデントは caller_id。報告した人が基準です。障害を上げた本人の画面に出ます。

申請明細は requested_for。申請した人ではなく、申請の対象になった人が基準になります。上司が部下のために申請したら、一覧に出るのは部下の側です。

業務アプリ申請は assigned_to。担当者が基準です。頼んだ人ではなく処理する人の画面に出ます。4件のなかでこれだけ性格が違いました。

同じタブを押しても、テーブルごとに違う列で絞られている。この事実は、問い合わせ対応のときに知っておく価値があります。

sc_request だけ条件が1つ多い

カタログ申請の For you には、もうひとつ条件が付いていました。universal_requestISEMPTY が先頭にあります。

ユニバーサルリクエストに紐づいている申請は、一覧から外すという意味です。上位の依頼にぶら下がっているものを二重に見せない配慮でしょう。

4テーブルのなかでこれだけ例外的な条件を持っています。カタログ申請が他の仕組みと繋がりやすい位置にあるためだと考えられます。

For others は2テーブルだけ

For others の条件があるのは incident と sc_request の2つだけでした。sc_req_item と business_app_request にはありません。

タブ自体は3つとも表示されるはずですが、条件が無いテーブルは絞り込みの対象になりません。ここは実際の画面を見て確かめたいところです。

インシデントの条件は caller_id!= で始まり、自分以外を指します。カタログ申請は opened_by を使っていて、判定に使う列が For you（requested_for）と違いました。同じテーブルでも、タブによって見る列が変わります。

Status と Updated は4テーブル共通

一方で、Open と Closed は4テーブルとも同じ条件でした。active=true^EQ と active=false^EQ です。

active フィールドはどのタスク系テーブルにもあるので、共通で書けます。Last 7 days と Last 30 days も sys_updated_on を見ていて、こちらも共通です。

テーブル固有の事情があるのは「誰の申請か」だけで、状態と期間は共通化できています。この切り分けが構造をすっきりさせています。

22件のクエリを読むと何が分かるか

条件のフィールドには、エンコード済みクエリがそのまま入っています。ServiceNow の一覧画面でフィルタを作ると生成される、あの文字列です。

active=true^EQ のように短いものもあれば、universal_requestISEMPTY^requested_forDYNAMIC… のように複合したものもあります。読み方さえ分かれば、画面を開かずに動きが追えます。

DYNAMIC に続く長い英数字は、動的フィルタの sys_id です。「ログイン中のユーザー」のような、実行時に決まる値を指します。固定の sys_id を書くと特定の人にしか効かないので、この形が使われています。

javascript: で始まる書き方も混ざっていました。インシデントの For others は caller_id!=javascript:gs.getUserID() です。同じ「ログイン中のユーザー」を、こちらはスクリプトで取っています。

同じ意味の条件が2通りの書き方で入っているわけです。作られた時期が違うのだと考えられます。動くので問題は無いものの、統一されていない箇所として記録しておきます。

Status と Updated が共通化できる理由

4テーブルで同じクエリが使えるのは、共通の親テーブルを持つためです。

sc_request も incident も sc_req_item も、元をたどれば task を継承しています。active も sys_updated_on も、親の側で定義されている列です。

だから active=true^EQ が全部で通ります。テーブルごとに書き分ける必要がありません。

一方で「誰の申請か」は親には無い概念でした。caller_id はインシデント固有、requested_for は申請系固有。ここだけ書き分けが必要になります。

継承の構造を知っていると、この違いが自然に見えます。共通化できるところと、できないところの線が引けるためです。

タブとフィルタの紐付け

5つ目のテーブル sn_ex_sp_request_tab_filter_mtom には6件ありました。

中身は単純でした。3つのタブそれぞれに Status と Updated を紐づけているだけ。3 × 2 で6件です。組み合わせを明示的にレコードで持つことで、タブごとに使えるフィルタを変えられる余地を残しています。

つまり、どのタブを開いても状態と期間で絞り込める、という設定になります。タブによって使えるフィルタを変えることもできる構造ですが、標準では全部同じでした。

無効な Other タブにも紐付けが2件残っています。有効化したときにそのまま動くよう用意されています。

この5テーブルを触るときの順番

自分の環境で変更するなら、依存の向きに沿って進めます。

1. ソースを決める

まず何を一覧に出すかです。sn_ex_sp_request_source に行を足すか、既存の行の active を切り替えます。

見出しに使う列は慎重に選びます。short_description が空のレコードが多いテーブルだと、一覧が空白だらけになります。number のように必ず値があるものを選ぶほうが安全です。

2. 遷移先ページを確認する

portal_page に指定したページが存在しないと、行を押しても開きません。既存の4件が使っている3ページから選ぶのが無難でしょう。

独自ページを作る場合は、ポータルのページ定義側の作業になります。

3. 条件を書く

sn_ex_sp_request_filter_conditions に、テーブルと選択肢の組み合わせぶんだけ行を作ります。

最低でも Open と Closed は要ります。active を持つテーブルなら、既存の条件をそのままコピーできます。

「自分の」の条件は、そのテーブルで誰を基準にするかを決めてから書きます。ここが設計判断になる箇所です。

4. 動かして確かめる

定義を入れたら、実際にポータルを開いて確認します。テーブルの中身だけでは、表示の崩れや遷移の失敗は分かりません。

この記事で扱ったのは定義側だけ。画面での見え方は別に確かめる必要があります。

3つのタブが表す考え方

For you / For others / Other という並びは、利用者から見た関係性で分けたものです。

自分に関わる申請と、他人に関わる申請。この2軸で分けるのは、ポータルの利用者にとって自然な区切りでしょう。管理者向けの一覧なら「担当グループ別」や「状態別」で分けるところです。

誰の視点で作られた画面かが、タブの分け方に出ています。 ポータルは申請する側の画面なので、自分か他人かが先に来ます。

「他人の」を見る場面

For others があるのは、代理申請や上長の確認を想定しているためだと考えられます。

部下のために申請したもの、自分が起票して他の人が対象になっているもの。こうしたレコードは For you の条件に引っかかりません。だから別のタブが要ります。

インシデントの For others が caller_id!= で書かれているのは分かりやすい例です。自分が報告者でないもの、という単純な否定条件になっています。

タブが2つでも成立する設計

Other が無効なので、実際に見えるのは2タブです。それでも画面としては成立します。

3つ目を用意しておいて使わない、という状態は珍しくありません。標準機能を調べるとき、有効なものだけを数える習慣が要ります。

有効化するかどうかは各社の判断です。条件を自分で書けるので、「部署のメンバーの申請」のような独自の切り口を入れることもできます。

選択肢ごとに分けた画面です。どの条件が何テーブルぶん用意されているかが見えます。For others だけ2件しかないのが一目で分かる並びでした。

一覧に出ない申請を追うとき

この5テーブルを読んでも原因が分からない場合、別の層を疑うことになります。

権限で見えていない可能性

一覧の条件を満たしていても、ACL で弾かれていれば表示されません。条件と権限は別の層です。

「見えないのは本当に権限か」を切り分ける手順はServiceNowで「このレコードが見えない」は本当にACL拒否？にまとめました。まず条件、次に権限、という順番で見ると迷いません。

そもそも申請が作られていない可能性

カタログから申請すると、sc_request と sc_req_item が両方できます。片方だけ見ていると「無い」と判断してしまいます。

複数アイテムをまとめて頼んだ場合はさらに増えます。複数アイテムを1申請に束ねる（オーダーガイド）の仕組みが絡むと、レコードの数え方が変わります。

一覧に出るのは4テーブルぶんです。それ以外のテーブルに書かれた情報は、この画面には現れません。

インシデントは周辺テーブルにも書かれる

インシデント1件を作ると、本体以外にも記録が残ります。ServiceNowのインシデント1件は何テーブルに書かれる？で数えたとおりです。

一覧が見ているのは incident 本体だけ。周辺に何が書かれていても、表示には影響しません。

42件という規模をどう見るか

標準の定義が42件しかないのは、意外に少ない印象でした。

ただ内訳を見ると納得できます。4テーブル × 5〜6条件で22件。これがいちばん多い部分です。残りはフィルタの枠組みで、20件しかありません。

つまり増えるのは条件だけという構造になっています。テーブルを1つ足せば、条件が5件前後増えます。10テーブル出すようにすれば、条件は50件を超えるでしょう。

枠組みが小さく保たれているのは、この設計が効いているためです。フィルタの種類を3つに絞り、選択肢を7つに抑えた。その代わり、テーブルごとの差分は条件テーブルで吸収する。

拡張したときにどこが膨らむかが分かっていると、運用の見通しが立てやすくなります。

紐付けの6件はこの画面で全部見えます。3タブ × 2フィルタ。素直に並んでいるだけの単純な表でした。

用語

ソース：申請一覧に表示するテーブルの指定。sn_ex_sp_request_source に入る。

View Filter：タブとして描かれる絞り込み。「自分の」「他人の」で分ける。

Status フィルタ：開いているか閉じているかで絞る。複数選択できる。

Updated フィルタ：更新日で絞る。7日以内と30日以内の2つ。

DYNAMIC：クエリで動的な値を使う書き方。ログイン中のユーザーを指すときに使う。

ユニバーサルリクエスト：複数の申請をまとめる上位の依頼。カタログ申請の条件で除外されている。

実機を見て気づいたこと

「自分の」がこれほどバラバラだとは思わなかった

タブの名前が同じなら、判定も同じだと思い込んでいました。実際には caller_id、requested_for、assigned_to の3種類です。

考えてみれば当然でした。インシデントに requested_for はありませんし、業務アプリ申請に caller_id はありません。テーブルごとに持っている列が違うので、揃えようがない。

利用者から「出るはずのものが出ない」と言われたとき、まずどのテーブルの話かを確認する必要があります。ここを飛ばすと、見当違いの場所を調べることになります。

無効な選択肢が定義として残っている

Other が active=false で入っていたのは、設計の途中経過が見える例でした。

製品として3つ目のタブを構想したものの、条件を決めきれなかった。消さずに無効で残してある。order も振ってあるので、位置は決まっています。

こうしたレコードは、標準機能を調べているとときどき見つかります。無効なものを数に入れて「3タブある」と説明すると、実物と合いません。active を必ず確認するという基本が効く場面です。

5テーブルに分けた理由が読める

42件しかないのに5テーブル。最初は分けすぎに見えました。

役割を追うと理由が分かります。ソースはテーブルの指定。定義はフィルタの種類。設定は選択肢で、条件は実クエリ。紐付けはタブとの組み合わせです。変わる頻度も、変える人も違います。

新しいテーブルを一覧に足したいなら、ソースに1行足すだけ。フィルタの選択肢を増やしたいなら、設定と条件に足す。片方だけ触れる構造になっています。

実務では何に使えるか

「出てこない」の切り分け手順

利用者からの問い合わせに答えるとき、順番があります。

まず対象のテーブルを確認します。カタログ申請なのか、その明細なのか。REQ番号かRITM番号かで分かります。

次にそのテーブルの For you 条件を見ます。sn_ex_sp_request_filter_conditions で table と filter_config を指定すれば、実際のクエリが読めます。

最後にレコード側を確認します。条件で見ている列に、その利用者が入っているか。requested_for を見ているのに opened_by にしか入っていない、というのがよくある原因です。

承認で止まっているケースは別の話になります。ServiceNow 承認（Approval）完全ガイドを参照してください。

自社のテーブルを一覧に足す

独自に作った申請テーブルを一覧に出したい場合、sn_ex_sp_request_source に1行足します。

必要なのは4つ。テーブル名と、見出しに使う列。補足に使う列と、遷移先ページです。既存4件が見本になります。

あわせて sn_ex_sp_request_filter_conditions にも行が要ります。そのテーブルで「自分の」をどう判定するかを決めて、クエリを書きます。ここを飛ばすと、タブを押しても絞り込まれません。

既定ポータルの前提を確認する

この5テーブルは sn_ex_sp_ という接頭辞を持っています。Employee Center 系の仕組みです。

既定ポータルがどう構成されているかは既定ポータル Employee Center（/esc）はカタログを持たないで扱いました。従来の Service Portal とは作りが違います。

自分の環境がどちらを使っているかで、触る場所が変わります。ServiceNow Service Portalはどこを直せば画面が変わる？とあわせて確認する順番になります。

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

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

• 一覧に出すテーブル：/sn_ex_sp_request_source_list.do

• フィルタの種類：/sn_ex_sp_request_filter_definition_list.do

• フィルタの選択肢：/sn_ex_sp_request_filter_config_list.do?sysparm_query=ORDERBYreq_filter_definition

• 実クエリをテーブル別に見る：/sn_ex_sp_request_filter_conditions_list.do?sysparm_query=GROUPBYtable

• タブとフィルタの紐付け：/sn_ex_sp_request_tab_filter_mtom_list.do

引用した公式説明を自分で開く

この記事で引用した説明文は、ServiceNow が製品に同梱しているフィールドのドキュメントです。次のURLを自分のインスタンスで開けば、引用元の原文にあたれます。

• フィールドの公式説明（引用元）：/sys_documentation_list.do?sysparm_query=nameINsn_ex_sp_request_filter_definition,sys_filter^hintISNOTEMPTY

検証範囲とおことわり

Australia の PDI（OOTB）で 2026-08-10 に確認しました。件数はこの環境の実測値です。

確認していないことがあります。ポータル画面を実際に開いて、この定義がどう表示されるかは見ていません。テーブルのレコードから構造を読み取った内容です。

独自のソースやフィルタも追加していません。DYNAMIC に続く sys_id が指す動的フィルタの中身も追っていません。

business_app_request というテーブルの用途そのものは、この記事の対象外としました。一覧に出るソースの1つとして名前が出てくるだけです。

5つのテーブル名は、Australia の新規テーブル一覧に含まれていました。Zurich 側に同等の仕組みが別の名前であったかは調べていません。

関連記事

• ServiceNowの申請1件はなぜ3テーブルに分かれる？ — 一覧に出る4テーブルのうち2つの関係

• 既定ポータル Employee Center（/esc）はカタログを持たない — この仕組みが載るポータル

• ServiceNowのポータル画面1枚は何でできている？ — 画面の組み立てを追う