メインコンテンツへスキップ

/swp のトップが検索でなくカテゴリ一覧になる理由(homepage)


    ServiceNow には利用者向けの「ポータル」が複数登録されています。多くは検索ボックスを大きく置いた「まず検索してください」というトップ画面から始まる構成です。その中に1つだけ、開いた瞬間にカタログのカテゴリ一覧が並ぶポータルがあります。それが Service Workspace Portal(/swp)です。

    この記事では、/swp を PDI(個人用の検証インスタンス)の初期状態で実際に開き、設定値・テーマ・ページ・ウィジェットまで REST と実画面で読み解く開発者向けリファレンスです。前半で「開くと何が並び、どの機能への入口になっているか」を押さえます。後半では「その見た目を裏で決めている sp_portal の設定・テーマの中身・ホームのウィジェットが持つコードと公開範囲」を実測ベースで並べます。この記事だけを見れば /swp を「設定・開発できる」レベルまで把握できることを目標にしました。テーブルの内部構造(sp_portal → sp_page → sp_widget のつながり方)そのものは別記事に譲り、本記事は「どの設定がどの画面・どのコードにつながるか」に集中します。

    確認した環境:ServiceNow PDI(Personal Developer Instance)/ Zurich(ズーリッヒ)リリース/ OOTB(初期設定のまま)/ 確認日 2026-07-11。本番環境やカスタマイズ済みの環境では、見た目・カテゴリ・アイテムが異なる場合があります。ここに書いた数値・状態は、このPDIで実際に見えた・REST で読み取れたものだけを記載しています。ロールやライセンスの違う利用者での表示差、テーマの SCSS コンパイル結果、ワークスペース連携の詳細は本記事の範囲外です。


    このポータルは何か(homepage=sw_sc_category=カタログ起点)

    先に結論を言うと、Service Workspace Portal は「カタログのカテゴリ画面をトップに置いたポータル」です。他の多くのポータルが検索用の大きなヒーローから始まるのに対して、これは最初からカテゴリの一覧が並びます。

    ポータルの定義は sp_portal テーブルにあります。今回確認した PDI で /swp の1件を読み取ると、url_suffix は swp、homepage は sw_sc_category でした。ポイントは homepage です。sp_portal の homepage は「そのポータルを開いたときに最初に表示するページ(sp_page)」を指します。sw_sc_category は名前のとおり「サービスカタログのカテゴリを表示するページ」なので、/swp を開くと検索欄ではなくカテゴリの一覧が最初に出ます。

    参考までに、同じ PDI で他のポータルの homepage を見ると、Service Portal(/sp)は index が入口でした。Employee Center(/esc)は ec_standard_home という別のページが入口です。どのポータルも同じカタログを扱える一方で、入口として最初に何を見せるかはポータルごとに違う、という構造です。/swp はその入口をカテゴリ画面に固定した位置づけになります。

    theme は Workspace EC Theme、dark_theme は Workspace EC Dark theme で、ワークスペース系のテーマが割り当てられていました。テーマの中身(配色を決める SCSS 変数や header/footer の指定)は後半の「デザイン設定の詳細」で掘り下げます。このポータルがワークスペース(エージェント向け画面)とどう連携するかは今回は確認していません(検証範囲外)。ここでは登録上の事実として押さえておきます。


    見た目:パンくず・Categories・Popular Items

    実際に /swp を開くと、次の画面が表示されました。


    画像

    画面を分解すると、要素は大きく4つでした。

    パンくず(上部左)は Home > Service Catalog > All Categories。いま「サービスカタログの全カテゴリ」を見ている、という現在地を示します。homepage=sw_sc_category のとおり、開いた直後が All Categories になっています。Search Catalog(上部右)はカタログ内を検索する入力欄です。検索が中央に大きくではなく右上に控えめに置かれているのが、検索起点のポータルとの見た目の違いになります。

    Categories(左カラム)はカタログのカテゴリ一覧です。今回の画面では、Business Application Lifecycle M…/Can We Help You?/Hardware/Office/Peripherals/Quick Links/Role Delegation/Software/Standard Changes の9件が並んでいました。Hardware・Office・Software・Standard Changes の左には展開アイコンがあり、下位カテゴリを持つことが分かります。

    Popular Items(右カラム)はよく使われるアイテムのカードです。今回は Standard Laptop(Lenovo - Carbon x1 / $1,100.00)と ソフトウェア利用申請 の2件が出ていました。各カードには View Details のリンクがあります。右上のグリッド/リスト切替アイコンは、この Popular Items の見せ方をタイルと一覧で切り替えます。今回はグリッド表示が選択されていました。

    つまり /swp のトップは「左でカテゴリを選び、右で人気アイテムを眺め、必要なら右上で検索する」という、カタログを起点にした申請導線になっています。ここに並んでいたカテゴリと人気アイテムは、架空のダミーではなく、このインスタンスに登録済みのレコードがそのまま出たものでした。

    Categories は sc_category から来る

    左カラムの Categories は、sc_category テーブル(カタログのカテゴリ)の内容が反映されたものです。sp_portal の sc_catalog が Service Catalog を指しているので、この画面には Service Catalog に属するカテゴリが並びます。今回の PDI で Service Catalog に属し、親カテゴリを持たない(トップ階層の)有効なカテゴリを読み取ると、画面に並んでいた9件と同じ顔ぶれ(Hardware / Office / Software / Peripherals / Quick Links / Role Delegation / Standard Changes / Business Application Lifecycle Management / Can We Help You?)が確認できました。展開アイコンを持つ Hardware などは、その下に Laptops / Desktops / Tablets といった下位カテゴリを親子として持っています。

    なお REST でトップ階層の有効カテゴリを数えると、画面の9件のほかにいくつか(例:Virtual Resources / Top Requests)も返ってきました。画面に出るカテゴリは、カテゴリ側の表示条件やポータル側の設定で絞られることがあり、「sc_category にある=必ずこの画面に出る」わけではありません。この記事では「画面に9件並んでいた」という事実と「その9件が sc_category に実在する」という裏取りにとどめ、絞り込みロジックまでは追いません(検証範囲外)。

    Popular Items は実データのカタログアイテム

    右カラムの Popular Items に出ていた2件は、どちらも sc_cat_item(カタログアイテム)に実在するアイテムでした。


    画像

    Standard Laptop は価格 1,100(画面の $1,100.00 と一致)で Hardware カテゴリ、ソフトウェア利用申請は価格 0 で Software カテゴリでした。ソフトウェア利用申請は日本語で登録されたアイテムで、説明にも「業務で使うソフトウェアの利用を申請します。上長承認の後、サービスデスクが払い出します」とありました。これらはこのインスタンスのカタログに登録済みのアイテムがそのまま「人気」として表示されています。Popular(人気)がどういう基準で選ばれているか(注文実績か、手動指定か)は今回は確認していません。ここで言えるのは、表示されている2件がカタログの実アイテムであるという点までです。


    基本設定(sp_portal)

    ここからがリファレンス部分です。/swp の見た目と挙動を決めているのは sp_portal レコードの設定値です。REST で読み取れた、値のある項目を意味とあわせて並べます。


    画像

    押さえどころは次のとおりです。入口とページ差し替えは homepage(最初に開くページ)、login_page(未ログイン時)、notfound_page(404)の3つで、それぞれ別の sp_page を指します。ページを丸ごと差し替えたいときはここを変えます。見た目は theme=Workspace EC Theme が担い、dark_theme にも Workspace EC Dark theme が入っていました。/sp(Coral・dark_theme 未設定)と比べると、/swp はダーク用テーマまで割り当て済みという違いがあります。

    /sp との差がもう1つ出るのが検索です。/swp は enable_ais=false で、AI Search を使わない設定でした。カタログは sc_catalog=Service Catalog を参照し、左のカテゴリ一覧と人気アイテムはこのカタログに紐づいて表示されます。css_variables には基本フォント(SourceSansPro ほか)を指定する SCSS 変数が入っていました。quick_start_config にはガイド付き設定でつなぐ要素(readonly_variable_editor)が入っています。rtl_enabled=true(右横書き対応)、enable_favorites=false(お気に入り無効)は、そのまま読み取れた値です。enable_embeddables=false も同様でした。

    表に出していない項目(ナレッジ関連の kb_knowledge_base、検索アプリ、ロゴ、sp_rectangle_menu など)は、このPDIでは空でした。空でも動くのは、ServiceNow 側が既定のページや挙動にフォールバックするためで、明示的に指定したいときにだけ値を入れる、という位置づけになります。


    画面遷移:/swp からどこへ行けるか

    /swp の Service Workspace Portal は、sp_portal の設定を通じていくつかのページへ分かれます。どの設定から、どのページへ到達するかを一枚にまとめました。


    画像

    読み方は次のとおりです。ポータル本体(sp_portal)が直接指すページは3つです。内訳は homepage=sw_sc_category(起点)、login_page=login(ログイン)、notfound_page=404(Not Found)です。/sp のようにヘッダメニュー(sp_rectangle_menu)から枝分かれするページはありません。/swp の sp_rectangle_menu は未設定で、ヘッダの独自メニュー項目は定義されていませんでした。

    ページ遷移は、URL でいうと /swp?id=<ページのid> という形をとります。ホームは /swp?id=sw_sc_category です。この id が sp_page レコードの識別子で、ポータル設定は「どの id のページを開くか」を指定している、という関係になります。図で黄色く示した sw_sc_category が、このポータルの性格を決めている起点です。


    デザイン設定の詳細(Workspace EC Theme)

    /swp の配色と文字色を担っているのは、sp_portal の theme が指す Workspace EC Theme(sp_theme の1レコード)です。設定表の1行で終わらせず、テーマ側の項目を REST で開いて中身を並べます。


    画像

    読みどころは次の3点です。

    • ヘッダ・フッタは明示指定なしで非固定:header・footer はどちらも未設定で、ヘッダ/フッタのウィジェットをテーマ側で明示していません(既定にフォールバック)。navbar_fixed=false・footer_fixed=false なので、スクロールしてもヘッダを上部に貼り付けたりフッタを下部に固定したりはしません。専用テーマで濃紺ヘッダを固定していた CAB Workbench(navbar_fixed=true)とは、この点が対照的です。

    • 文字色は Now の色トークンを参照しています。css_variables には SCSS 変数が入っていました。値は $text-primary: sp-rgb(--now-color_text--primary, #181A1F ); です。sp-rgb(--now-color_text--primary, …) という書き方は、Now Design System の色トークン(CSS カスタムプロパティ)を第一候補にする指定です。フォールバックとして #181A1F を持ちます。配色を単独の固定色でベタ書きするのではなく、Now 側のテーマ変数に寄せている点が読み取れます。あわせて matching_now_experience_theme=Coral が入っていました。このテーマは Next Experience(Now)側の Coral テーマと対応づけられています。

    • ロゴ・アイコン・ダークは外側で持つ:テーマ側の logo・icon はどちらも未設定でした。一方でダークモード用の dark_theme(Workspace EC Dark theme)は、テーマ側ではなく sp_portal 側の設定として割り当て済みです。ダーク配色を差し替えたいときは、この dark_theme が指す別テーマを触る形になります。

    テーマの各 SCSS 変数が最終的にどの要素へ効くか(コンパイル後のCSS)までは今回の読み取りの範囲外です。ただし「文字色=Now の色トークン参照」「対応 Now テーマ=Coral」という対応は実測できました。ポータル設定 css_variables の基本フォント指定(SourceSansPro)と、テーマ側 css_variables の色指定は別レコードです。フォントはポータル単位・色はテーマ単位で上書きされる、という二段構えになっています。


    関連するウィジェット

    /swp で「部品を変えたい」ときの対象は、ほぼウィジェットに集約されます。ホームと各ページに載っているウィジェットを実測しました。

    ホームのウィジェット構成

    ホーム(sw_sc_category=Category Landing)は、2個のウィジェット配置(sp_instance)でできていました。どのコンテナに、どのウィジェットが置かれているかを実測しました。


    画像

    わずか2配置ですが、画面に見えた要素はこの2つが分担して描いています。名称と実描画から読み取ると、SC Categories が左カラムのカテゴリ一覧を、SC Category Page がパンくず・カテゴリ内のアイテム表示・カタログ検索を担っていると読み取れました。ウィジェット本体(sp_widget)の description はどちらも空だったため、この役割分担は公式の説明文ではなく実描画からの読み取りである点はおことわりしておきます。

    widget id は、SC Categories が未設定、SC Category Page が sc-category でした。同じ「1ページ=複数ウィジェットの配置」という Service Portal の作りは /swp でも共通です。ただし /sp のホーム(index)が16配置だったのに対し、/swp のホームは2配置と最小構成です。トップでやることをカタログのカテゴリ表示に絞っている、という設計が配置数にも表れています。

    各ページのウィジェット

    ホーム以外の遷移先ページにも、それぞれウィジェットが載っています。ページごとの中身を実測しました。


    画像

    ページごとに性格がはっきり出ています。ログインページ(login)は Login ウィジェット1つで、ログインフォームが中心の最小構成です。404(Not Found)は HTML と Breakout Game の2つで、OOTB の 404 ページにはブロック崩し風のミニゲームウィジェットが載っていました。ページが無いときに遊びのある画面を出す作りは /sp の 404 と同じ顔ぶれです。

    /swp の3ページはいずれも構成が軽く、ヘッダメニューが無いぶん「起点のカテゴリ画面」に機能が集約されている点が読み取れます。ナレッジや申請状況を集めた総合トップを持つ /sp とは、ページ数・ウィジェット数の両面で対照的でした。


    ヘッダーメニュー等の設定(sp_rectangle_menu は未設定)

    /sp の Service Portal はヘッダに Knowledge・Catalog・Requests などのメニューが並び、そこから各ページへ枝分かれしていました。/swp はここが大きく違います。sp_rectangle_menu(ヘッダのメインメニュー定義)が空で、sp_rectangle_menu_item(各メニュー項目)のレコードも0件でした。つまりヘッダ由来の遷移先ページは存在しません。


    画像

    遷移先は、すべてポータルフィールドが直接指す3ページ(sw_sc_category / login / 404)に集約されます。画面上部のパンくずや Search Catalog は、メニュー定義ではなく前節のウィジェット(SC Category Page)が描いているものです。/swp は「ヘッダにメニューを並べて多方向に案内する」のではなく、「トップ=カタログのカテゴリ画面に絞り、そこからカテゴリとアイテムをたどらせる」構成になっています。この割り切りが、他ポータルとの操作感の違いにつながっていました。ヘッダにメニューを足したいときは、sp_rectangle_menu に定義を作り sp_rectangle_menu_item を追加する、という余地は残っています。


    ビジネスルール・スクリプト等の周辺機能

    見た目の裏側で動くコードと公開範囲へ進みます。/swp の周辺機能は、ホームを描く2つのウィジェットが持つスクリプトと、その公開設定に集約されます。

    ホーム2ウィジェットの周辺機能

    ホームの SC Categories と SC Category Page が、どんな公開範囲・コード・依存を持つかを実測しました。


    画像
    • 公開範囲:どちらも public=false で、未ログインでは表示されません。roles には snc_external と snc_internal が入っていました。外部ユーザー(snc_external)と内部ユーザー(snc_internal)の両ロールに表示される設定です。roles が空だった CAB Workbench のカレンダーウィジェットとは異なり、こちらは明示的にロールが指定されています。

    • 保持するコード:SC Categories は server / client / link / options / css / html を持ちます。SC Category Page は server / client / options / css / html を持ちます。どちらもサーバスクリプト・クライアントスクリプト・CSS・HTMLテンプレート・オプションを備えたフル構成です。SC Categories はこれに link(Angular のリンク関数)が加わっていました。

    • 依存(dependencies):どちらも依存レコードは持っていませんでした。CAB のカレンダーウィジェットが専用の JS/CSS 依存を2本読み込んでいたのに対し、この2つは追加の依存を束ねずに動く構成です。

    カタログ系ウィジェットのスクリプトモデル

    外形が分かったところで、この2つが Service Portal のウィジェットとしてどう動くかの一般的なモデルを補足します。Service Portal のウィジェットは、サーバスクリプトが data / input オブジェクトを介してクライアント側へ値を受け渡す作りが基本です。サーバ側では GlideSPScriptable($sp)系の API や Script Include を通じて情報を読み取ります。対象はカタログのカテゴリ(sc_category)やアイテム(sc_cat_item)です。その結果を data に載せます。クライアント側の Angular コントローラは受け取った data を HTML テンプレートへ描画します。link 関数や依存(Provider / Template)で追加の描画処理を組み立てます。

    SC Categories と SC Category Page が実際にどのテーブルへどんなクエリを投げているかは、今回の読み取りの範囲外です。クライアント側のコントローラが何をしているか、個別のスクリプト内容も同様に範囲外です。ここでは「public/roles・保持するコードの種類・依存の本数」という外形を実測しました。Service Portal ウィジェットの一般的なスクリプトモデルに沿った構成である、という整理にとどめます。ビジネスルール(sys_script)など、テーブル側で動く処理はポータルの外側の話なので、本記事では扱いません。


    開発者の勘所とまとめ

    開発者の勘所

    /swp を設定・開発する観点で、押さえておくと迷いにくいポイントを挙げます。

    • ページ遷移は ?id=<page> 形式。ポータル設定が指すのは sp_page の id(sw_sc_category / login / 404)です。URL も /swp?id=... になります。

    • 入口がカタログのカテゴリ画面。他ポータルが検索ヒーローやホーム起点なのに対し、/swp は homepage にカテゴリ表示ページを指定することで、開いた直後をカテゴリ一覧に固定しています。見た目の印象の違いが、テーブルの1フィールド(homepage)の違いに対応します。

    • 配色はテーマの SCSS 変数、フォントはポータルの css_variables。文字色は theme(Workspace EC Theme)の css_variables が Now の色トークン($text-primary: sp-rgb(--now-color_text--primary, …))を参照して決め、基本フォントは sp_portal 側の css_variables(SourceSansPro)で上書きしています。ダークは dark_theme(Workspace EC Dark theme)が担当します。

    • 扱うカタログの供給元は sc_catalog。左のカテゴリと人気アイテムは Service Catalog に紐づきます。差し替えるならここです。検索の挙動は enable_ais(このPDIは false)、右横書き対応は rtl_enabled(true)で切り替わります。

    • ヘッダメニューを持たない。sp_rectangle_menu が未設定で、遷移はポータルフィールドの3ページに集約されます。多方向の案内が要るなら、メニューを組むより別ポータル(/sp など)が向きます。

    • カスタマイズの起点はホームの2ウィジェット。SC Categories と SC Category Page が public=false・roles=snc_external/snc_internal・server/client/css/html/options(+SC Categories は link)を持ち、依存はなし。部品単位で変えたいなら sp_instance / sp_widget を見ます。

    他のカタログ導線との違い(/sp・/esc)

    /swp は、ワークスペース系のテーマをまとった、カタログを主役にした申請ポータルです。開いてすぐカテゴリが並ぶため、「何を申請できるか、カテゴリから探したい」という使い方に向いています。同じ PDI にある他のカタログ導線と比べると、入口の考え方の違いがはっきりします。

    • Service Portal(/sp):「How can we help?」という大きな検索ヒーローが主役です。カタログは Request Something という導線の1つとして置かれ、ナレッジ検索や申請状況(My Open Incidents など)も同じトップに並びます。homepage は index。

    • Employee Center(/esc):中央に検索を大きく置きます。Quick links や Popular topics、My active items など社員の入口として広く情報を集約します。homepage は ec_standard_home で、カタログはそのなかの一部です。

    • Service Workspace Portal(/swp):入口そのものがカタログのカテゴリ画面(homepage=sw_sc_category)。検索は右上に控え、トップの主役が最初から「カタログのカテゴリと人気アイテム」になっています。

    どれも同じ Service Catalog を扱えます。ただし /sp・/esc が「検索・お知らせ・申請状況を集めた総合トップ」なのに対し、/swp は「カタログのカテゴリ表示に絞ったトップ」という違いがあります。この差は、sp_portal の homepage に何のページを指定しているかという設定に現れていました。

    まとめ

    • /swp の Service Workspace Portal は、sp_portal に登録されたカタログ起点のポータル。url_suffix=swp、default=false、homepage=sw_sc_category、login_page=login、notfound_page=404、theme=Workspace EC Theme、dark_theme=Workspace EC Dark theme、sc_catalog=Service Catalog。

    • デザインは Workspace EC Theme が担い、header/footer 未設定・navbar_fixed=false・文字色は Now の色トークン参照($text-primary: sp-rgb(--now-color_text--primary, #181A1F ))・対応 Now テーマは Coral・logo/icon 未設定という中身でした。

    • enable_ais=false(AI Search 未使用)、sp_rectangle_menu は未設定でヘッダ独自メニューなし。遷移先はポータルフィールドが直接指す3ページに集約されます。

    • ホーム(sw_sc_category)は SC Categories と SC Category Page の2配置で構成。両ウィジェットとも public=false・roles=snc_external/snc_internal・server/client/css/html/options を持ち、依存はなし(SC Categories は link も保持)。login は Login 1件、404 は HTML+Breakout Game の2件でした。

    • 左の Categories は sc_category の実データです。右の Popular Items(Standard Laptop / ソフトウェア利用申請)は sc_cat_item の実データとして裏取りできました。

    用語

    • sp_portal:ポータルの定義を1件1レコードで持つテーブル。url_suffix・homepage・theme・sc_catalog などのフィールドで、そのポータルの入口と見た目を決めます。

    • sp_page:ポータル内の1ページ。?id=<id> の id がこのレコードの識別子です(例:sw_sc_category / login / 404)。

    • sp_theme:ポータルの配色・文字色・ヘッダ/フッタを決めるテーマ。css_variables の SCSS 変数や matching_now_experience_theme を持ちます。

    • sp_rectangle_menu / sp_rectangle_menu_item:ヘッダのメインメニュー定義と各項目。/swp ではどちらも空でした。

    • sp_widget / sp_instance:ウィジェット本体と、ページ上への配置。本体は server/client/css/html/options などのコードと public/roles・依存を持ちます。

    • sc_catalog / sc_category / sc_cat_item:カタログ本体・カテゴリ・アイテムのテーブル。/swp の左カテゴリと人気アイテムはここから供給されます。

    関連記事

    検証範囲とおことわり

    • 確認したのは System Administrator(管理者)ログインでの見た目です。あわせて sp_portal / sp_page / sp_theme / sp_widget / sc_category / sc_cat_item の値も確認しました。ロールやライセンスの違う一般ユーザーでの表示差は未検証です。

    • ウィジェットの description は今回対象分がすべて空でした。SC Categories / SC Category Page の役割分担は名称と実描画からの読み取りで、公式の説明文ではありません。

    • ウィジェットのサーバ/クライアントスクリプトが内部で何をするか、link 関数や依存が束ねる個別コードの中身は本記事の範囲外です。public/roles・保持するコードの種類・依存の本数という外形のみ実測しました。

    • Categories の「どのカテゴリを出す/出さない」の絞り込みロジック、Popular Items の「人気」の判定基準は確認していません(検証範囲外)。

    • テーマの SCSS 変数がコンパイル後にどの要素へ効くか、各変数の全量は範囲外です。$text-primary が Now の色トークンを参照する点と、対応 Now テーマが Coral である点のみ確認しています。

    • 数値・状態はこのPDIの実測値であり、環境によって異なります。

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

    自分のインスタンスで同じ値を確認するには、次のURLが使えます(先頭の <YourInstance> は自分のインスタンスに置き換えてください)。

    ポータル定義(swp)   : sp_portal_list.do?sysparm_query=url_suffix=swp
    テーマ(sp_theme)     : sp_theme_list.do
    カタログのカテゴリ     : sc_category_list.do
    カタログアイテム       : sc_cat_item_list.do

    Service Workspace Portal を内部のテーブル(sp_portal → sp_page → sp_widget)の観点から見たい場合は、ポータル1画面は複数テーブルの組み合わせ(sp_portal) で、ポータル・ページ・ウィジェットのつながりを整理しています。

     
     
    ServiceNowのPDI(Personal Developer Instance)を実機で観察して、Noteに記事を書いています 実装・運用・教育の現場視点で淡々と記録中です リクエストがあればその記事も書きます 個人の観察日記です

    あなたへのおすすめ