ポータルモジュールの概要
ポータルを新しく作ろうとすると、最初に手が止まるのは「もう何か入っているのではないか」という疑問です。標準で10種類のポータルが用意されており、それぞれ画面の作りも提供する機能も違います。Australia版の開発検証環境で10ポータルすべてを実際に開き、検索・カタログ・ナレッジ・ヘッダーメニューを触って何が起きるかを確かめました。
ポータルモジュールの3つのポイント
標準ポータルは10種類です。開ける範囲ですべて画面を確認しました。
主役の2ポータル（Service Portal・Employee Center）は、検索・カタログ・ナレッジ・ヘッダーメニューという同じ4つの部品を持ちますが、画面の作り込みが違います。
残り8ポータルは、そのまま使えるもの・管理者向けの別UI・権限や設定で止まるものに分かれます。
検証環境：Australia PDI / OOTB / 2026-09-22 確認
この記事が対象にする範囲は次のとおりです。
Service Portal（sp_*）：sp_portal に10件登録されている、エンドユーザー向けのポータル定義です。
今回はこのうち10件すべてのトップ画面を開き、主役の2ポータル（Service Portal・Employee Center）は検索・カタログ・ナレッジ・ヘッダーメニューまで実際に操作しました。送信・申請・保存のボタンは押していません。入力したのは検索語だけです。
ポータルとは何か
公式の用語集は Service Portal を次のように説明しています。
Service Portal allows you to build a mobile-friendly self-service portal experience for your employees or customers. Service Portal is a ServiceNow AI Platform feature that is active by default and interacts with parts of the platform so users can access platform features through portals.
（訳: Service Portal を使うと、従業員や顧客向けに、モバイル対応のセルフサービスポータルを構築できます。Service Portal は ServiceNow AI Platform の機能です。既定で有効になっており、プラットフォームの一部と連携することで、利用者はポータル経由でプラットフォームの機能にアクセスできます）
引用元：Service Portal
ポータルの作り方そのものについては、公式ドキュメントに手順がまとまっています（ポータルを作成する）。ただし本記事の主題は「作り方」ではなく「標準で何が入っていて、どう動くか」です。ゼロから部品を選ぶ前に、既存の組み合わせで足りるかをまず確認します。
「ポータル」が指す部品の組み合わせ
1つのポータルは複数の部品を組み合わせてできています。ページは画面の単位、コンテナ・行・列は画面内の配置、ウィジェットは機能の部品、テーマは見た目の担当です。同じウィジェットでも配置するページやポータルを変えれば別の画面になります。この部品の組み合わせ方は、3章で Service Portal と Employee Center を実際に開きながら確かめます。
標準で入っているポータルの一覧
標準ポータルの一覧は、管理画面の sp_portal テーブルで確認できます。件数は10件で、既定（default=true）になっているのは Employee Center だけです。
10ポータルの一覧
内容を表にすると次のとおりです。
表の内容を文字でも書き出します。
Employee Center（esc／既定）：全社員向けの問い合わせ・申請の窓口です。
Service Portal（sp）：汎用セルフサービスで、Service Catalog と統合されています。
Knowledge Portal（kb）：ナレッジ記事の閲覧・検索専用です。
SP Configuration（sp_config）：ポータル管理者向けの設定ホームです。
Walk-up（walkup）：対面窓口（Walk-up Experience）向けです。
CAB Workbench（cab）：CAB（変更諮問委員会）のミーティング運営に使います。
Performance Analyzer（perf）：Performance Analytics のレポート閲覧に使います。
Benchmarks（benchmarks）：他社比較のベンチマーク指標を閲覧します。
Mobile Employee Service Portal（mesp）：モバイル端末向けの従業員ポータルです。
Service Workspace Portal（swp）：カテゴリ一覧型のワークスペースで、こちらも Service Catalog と統合されています。
10種類のうち、実務での判断対象になりやすいのは Employee Center と Service Portal の2つです。この2つは検索・カタログ・ナレッジ・ヘッダーメニューという同じ4つの部品を持ち、部門を横断して使う汎用ポータルという性格が共通しています。次の章では、この2つを実際に触って何が提供されているかを確かめます。残り8ポータルの外観は4章にまとめました。
ポータルは何を提供しているのか
Service Portal と Employee Center を実際に開き、検索・カタログ・ナレッジ・ヘッダーメニューをそれぞれ操作しました。カタログアイテムは開くだけで、Order Now は押していません。
Service Portal（/sp）の画面と機能
Service Portal のホームから、検索・カタログ・ナレッジ・ヘッダーメニューへどうつながるかを図にしました。
図から読み取れるのは、ホームが4つの入口（検索・カタログ・ナレッジ・ヘッダーメニュー）を持ち、カタログとナレッジはそれぞれ一覧画面から個別レコードの詳細画面へさらに1段深く進む構造だということです。
まずホーム画面です。ヘッダーに Knowledge・Catalog・Requests・System Status・Cart・Tours が並び、中央に検索の見出し「How can we help?」が出ています。中央には3つの主要な入口があり、赤枠で番号を振りました。
①の検索ボックスに語を入れると、次に見る検索結果画面に進みます。②の Request Something カードはカタログのトップへ、③の Knowledge Base カードはナレッジのトップへの入口です。この3つを順番に開いていきます。
検索：①の検索ボックスに語を入れると、専用の検索結果画面（id=search）に移ります。「laptop」で検索すると、Knowledge Bases と Catalogs の両方から該当するレコードが1つの画面にまとまって出てきました。
カタログ：②の Request Something カードを開くとカタログトップ（id=sc_home）に移ります。ここは「自分が申請した記録」を最初に見せる作りです。My Requests タブに過去の申請履歴が並び、右側に My Saved Bundles（保存済みのまとめ買い）が出ます。カタログトップにはもう1つ、①の Browse by Categories というリンクもあります。
①の Browse by Categories を押すと、カテゴリ別の商品一覧に進みます。これが商品を探すときの正規のルートです。
注意：Hardware カテゴリを開くと、1ページ目には9件だけが並び、残りは「Show More」を押して追加読み込みする作りでした。目的の商品（Standard Laptop など）が1ページ目に出ないことがあります。特定の商品を確実に探すなら、①のカテゴリを辿るより、先に見た検索を使うほうが早く見つかります。
カタログアイテムを1つ開くと（id=sc_cat_item）、商品説明・技術仕様・価格・数量・Order Now ボタンが並ぶ詳細画面になります。Standard Laptop（Lenovo Carbon x1）を開きましたが、Order Now は押していません。
ナレッジ：③の Knowledge Base カードを開くとナレッジトップ（id=kb_view2）に移ります。ここはカテゴリ別の件数を前面に出す作りで、IT・Devices・Email・Operating Systems などのカテゴリごとに記事数が並びます。
①の Email カテゴリのように、カテゴリごとに件数が表示されます。まずこの一覧からカテゴリを選ぶのが正規の探し方です。
注意：カテゴリの行を押すと kb_category のページに遷移しますが、表示される記事の一覧はカテゴリを選ぶ前と同じでした。カテゴリは分類の目安にはなりますが、絞り込みとしては機能していません。特定の記事を確実に探すなら、先に見た検索を使うほうが確実です。
記事を1つ開くと（id=kb_article_view）、タイトル・執筆者・更新からの経過・閲覧数・本文が並ぶ画面になります。「How to Deal with Spam」（KB0000011）という一般的な内容の記事で確認しました。
ヘッダーメニュー：右上のプロフィールをクリックすると、Profile と Logout の2項目だけが並ぶ小さなドロップダウンが開きます。
①が Profile、②が Logout です。項目はこの2つだけで、Employee Center のメガメニュー（後述）とは対照的な作りです。
Employee Center（/esc）の画面と機能
Employee Center も同じ4つの入口を持ちますが、画面の作り込みは Service Portal と別物です。
ホーム画面には、検索ボックスと2種類のカード（Quick links・Popular topics）が並びます。ヘッダーの下にはもう1段、「Technology services」から始まるメニュー行もありますが、これは後述のヘッダーメニューの項で扱います。
①の検索ボックスに語を入れると、次に見る検索結果画面に進みます。②の Quick links「Password reset」カードはカタログアイテムへの入口です。③の Popular topics「Email accounts」カードは、トピック経由でナレッジ記事につながる入口です。
検索：①の検索欄に語を入れる操作は Service Portal と同じで、専用の検索結果画面（id=search）に移ります。「password」で検索すると、カタログアイテムとナレッジ記事の両方が候補に出ました。
①の Sources パネルで、All・Knowledge Bases・Catalogs を切り替えて絞り込めます。②が検索結果1件目の「Password Reset」カードで、先ほどホーム画面の②で見た Quick links カードと同じ行き先です。
カタログ：カタログトップ（id=sc_home）を開くと、Service Portal とは違う画面になりました。My Requests 中心ではなく、Popular Items（人気アイテム）とカテゴリの一覧が並ぶ、閲覧・発見に寄った作りです。
①のサイドバー「Hardware」カテゴリを押すと、そのカテゴリの商品一覧を経由してアイテムへ進みます。次に開くカタログアイテムは、このカテゴリ経由で辿り着いた1件です。
同じ Standard Laptop をカタログアイテム画面（id=sc_cat_item）で開くと、Service Portal と同じ商品説明・価格が出ました。違うのは周りの作りで、パンくずリストの代わりに「< Back」の1本リンクになり、お気に入り登録用のハートアイコンが付きます。
①が商品タイトル、②が価格です。先ほど Service Portal で見たのと同じ内容が、ポータルをまたいでそのまま表示されています。
ナレッジ：ナレッジトップ（id=kb_home）は「Welcome to Knowledge」という見出しで、Knowledge Bases の件数と記事の件数が最初に出ます。
①のような Featured 記事カードを押すと、記事の詳細画面に進みます。ここでは比較のため、①とは別に、先ほど Service Portal で開いたのと同じ「How to Deal with Spam」を、Employee Center 専用のページ（id=esc_kb_article_view）で開き直しました。内容は同じです。変わっていたのは右側の関連パネルで、「Most Useful」から「Most Viewed」になっていました。
①が記事タイトル、②が執筆者・更新からの経過などのメタ情報です。
ヘッダーメニュー：Service Portal の単純なドロップダウンとは違う作りです。「Technology services」をクリックするとメガメニューが開きます。Hardware・Software・Network・Privacy and security の4カテゴリと、Quick links が横に並びます。
①は Hardware 列の中の「Computers」項目、②は Software 列の中の「Software and applications」項目です。それぞれ該当するトピックのページに進みます。③の「Browse Technology services」ボタンを押すと、Technology services 配下のトピック一覧にまとめて進みます。
公式の用語集は Employee Center をこう説明しています。
ServiceNow Employee Center portal is a standard multi-department, dynamic portal for service delivery, and employee engagement.
（訳: ServiceNow Employee Center ポータルは、複数部門にまたがるサービス提供と従業員エンゲージメントのための、標準の動的なポータルです）
引用元：Employee Center
「動的」という言葉のとおり、実機で見たとおりカテゴリカードや Popular topics の並びは利用者の操作に応じて変わる作りになっています。Service Catalog をポータルへどう出すかの一般的な考え方は、Service Catalog in Employee Center にもまとまっています。
ポータルに共通する部品
ここまでの実機確認から、Service Portal と Employee Center の画面の作り方について3つのことが分かります。
1つ目は、どちらのポータルも同じ5層構造（ページ→コンテナ→行→列→ウィジェット）で画面を組んでいることです。sp_page の下に sp_container、その下に sp_row、その下に sp_column と続き、そこに sp_instance として個別のウィジェットが配置されます。Service Portal のホームをこの階層でたどると、検索欄は「Homepage Search」という名前のウィジェットでした。見出しの「How can we help?」というテキストも、このウィジェットの設定値と一致していました。
2つ目は、URL の id= パラメータ（sc_home や sc_cat_item など）は複数のポータルで共通の呼び名として使われているものの、実体のページはポータルごとに別レコードだということです。同じ id=sc_home でも、Service Portal では申請履歴中心の画面、Employee Center では人気アイテム中心の画面と、まったく違う見た目になっていました。呼び名は共通でも、中身はポータルごとに独立して作り込まれています。
3つ目は、カタログアイテムのような業務レコードそのものは、ポータルをまたいでも同じ内容が出ることです。Standard Laptop の価格・説明は Service Portal でも Employee Center でも同じでした。変わるのは、パンくずリストか「< Back」か、お気に入りアイコンの有無といった、ページを囲む周辺部品の側だけです。
ウィジェットがどのテーブルにアクセスできるかは、システムプロパティで制御されています。
The glide.service_portal.widget.allow_list system property determines the list of widgets that are allowed to attempt to access any table on the instance.
（訳: glide.service_portal.widget.allow_list システムプロパティは、インスタンス上のどのテーブルにもアクセスを試みてよいウィジェットの一覧を決定します）
引用元：Configure Service Portal Widgets Allow List
ウィジェットの定義件数や、どこまで配置されているかの詳しい内訳は、次巻の「ポータルモジュールの設定」で扱う予定です。
タクソノミーとナレッジベースの連携
タクソノミー（taxonomy）は、トピックという単位でメニューの階層を管理する仕組みです。先ほどのメガメニューで見た Hardware・Software という列の正体も、このタクソノミーで管理されているトピックでした。
実機で taxonomy テーブルを確認すると、登録は Employee という1件だけでした。このタクソノミーは m2m_sp_portal_taxonomy を介して、Employee Center と Mobile Employee Service Portal の2ポータルに紐付いています。配下の topic は21件、階層は2段構成です。最上位は Technology services と Risk and compliance の2件で、残り19件はいずれかの配下に入ります。Technology services の配下には、メガメニューで見た Hardware・Software・Network があります。ほかには IT for IT・Developer services・Privacy and security などのトピックです。メガメニューの項目は、この21件のトピック構成そのものです。
ナレッジベースとの連携は、ポータルごとに作り方が違います。sp_portal には kb_knowledge_base（ナレッジベース）・kb_knowledge_page（ナレッジのホームページ）・sc_catalog（カタログ）・sc_catalog_page（カタログのホームページ）という4つの参照列があり、ポータルごとに実機で値を確認すると次のようになっていました。
Service Portal（/sp）：ナレッジベースに IT（Published 42件）を直接指定しています。先ほどのナレッジトップの節で見た件数は、IT ナレッジベース単体の値です。
Knowledge Portal（/kb）：ナレッジベースの指定は空でした。この後の Knowledge Portal（/kb）の項で見る「4 Knowledge Bases・42 Articles」という表示は、特定の1件を絞り込んだ値ではなく、登録済みの全ナレッジベースを横断して数えた値です。
Employee Center（/esc）：ナレッジベースもカタログも空で、ページの指定（esc_knowledge と esc_sc_category）だけを持ちます。中身の絞り込みは、上で見たタクソノミー（トピック）側で行う設計です。ナレッジベースを直接指定する Service Portal とは、連携の作り方が違います。
Service Workspace Portal（/swp）：カタログには Service Portal と同じ Service Catalog が指定されています。この後の Service Workspace Portal（/swp）の項で触れる「実体は /sp と同じカタログ画面」という結果は、この設定と一致します。
同じ「ナレッジ」「カタログ」という機能でも、ポータルごとに絞り込み方が違って見えるのは、この4列の組み合わせが違うためです。
残りのポータルはどんな画面か
残り8ポータルも実際に開きました。結果は「そのまま使える」「管理者向けの別UI」「権限や設定で止まる」「中身や専用ホームが無い」の4つに分かれます。
表の内容を文字でも書き出します。
Knowledge Portal（/kb）：開けた。そのまま使える専用ホーム。
Service Workspace Portal（/swp）：開けた。そのまま使える専用ホーム（実体はカタログ画面）。
CAB Workbench（/cab）：開けた。管理者向けの別UI（カレンダー）。
SP Configuration（/sp_config）：開けた。管理者向けの別UI（編集ツール）。
Benchmarks（/benchmarks）：オプトイン未実施の案内で止まる。権限・設定で止まる画面。
Performance Analyzer（/perf）：開けた（専用ホーム無し）。専用の中身が無い画面。
Mobile Employee Service Portal（/mesp）：PCでは白紙。専用の中身が無い画面。
Walk-up（/walkup）：権限エラーで止まる。権限・設定で止まる画面。
そのまま使える2つ（Knowledge Portal・Service Workspace Portal）は、開けばすぐに利用者へ見せられる画面でした。残り6つは3つの分類に分かれます。管理者向けの別UIは2つで、CAB Workbench と SP Configuration です。権限や設定で止まる画面も2つあり、Walk-up と Benchmarks が該当します。専用の中身を持たない画面は2つで、Mobile Employee Service Portal と Performance Analyzer です。
Knowledge Portal（/kb）
「Welcome to Knowledge」という見出しの専用ホームが開きました。Knowledge Bases が4件、Articles が42件という件数が最初に出ます。IT・KCS Knowledge Base（demo data）・Knowledge・Known Error の4つのカテゴリカードも並びます。ナレッジの閲覧・検索に特化した、検証環境で最も専用性の高いポータルの1つです。
さらに詳しい構成は、「45 Articles」はどこから来るか（kb_knowledge） にまとめています。
Service Workspace Portal（/swp）
開くといきなりカタログのカテゴリ一覧（All Categories）が表示されました。検索窓の代わりに、左側にカテゴリの一覧が並ぶ作りです。Service Catalog と統合されている点は Service Portal と共通しますが、トップページの構成は別物でした。
トップがカテゴリ一覧になる理由は、/swp のトップが検索でなくカテゴリ一覧になる理由（homepage） で確認済みです。
CAB Workbench（/cab）
他の9ポータルとは見た目がまったく違います。開くと最初から月表示のカレンダーが出て、Day・Week・Month の切り替えボタンが並びます。CAB（変更を諮る委員会）の会議運営に特化した専用UIです。
公式ドキュメントはこの画面の用途をこう説明しています。
CAB ワークベンチを使うと、変更要求のレビューと承認、および最近実装された変更のレビューができます。詳細は Working with the CAB Workbench にあります。ウィジェット1個でこのカレンダーが描かれている構成は、CAB Workbench（/cab）の入口はカレンダー1枚 で確認済みです。
SP Configuration（/sp_config）
管理者向けの編集ツールの入口が開きました。Branding Editor・Designer・Page Editor・Widget Editor・New Portal・Get Help という6枚のカードが並びます。ポータルを作る・直す側の人が使う画面だと一目で分かります。
このホームがウィジェット1個で6枚のカードを描いている構成は、/sp_config のホームはウィジェット1個 にまとめています。
Walk-up（/walkup）
「Sorry, you are not authorized to access the walk-up pages.」というエラーで止まりました。sn_walkup.walkup_login ロールを持つアカウントでないとアクセスできない仕組みです。
公式ドキュメントは、この制限を意図的な設計だと説明しています。
The Walk-up Experience on-site portal is accessed by an account containing only the sn_walkup.walkup_login role.
（訳: Walk-up Experience の対面窓口ポータルは、sn_walkup.walkup_login ロールだけを持つアカウントでアクセスします）
引用元：Walk-up Experience portal security and access
一般の管理者アカウントでは、権限が強すぎてこのポータルには入れません。受付端末（キオスク）専用の限定アカウントを使う前提の設計です。Walk-up Experience そのものの概要は Walk-up Experience にあります。
Benchmarks（/benchmarks）
開いても指標は出てきませんでした。「You are not opted in to ServiceNow Benchmarks.」という案内と、Opt-in ボタンだけの画面です。KPI や業界平均との比較を見るには、事前にオプトインの設定が要ります。
公式ドキュメントは、この機能が主要な業績評価の指標（KPI）と業界平均との比較を提供するものだと説明しています。詳細は Benchmarks をご覧ください。オプトインで止まる挙動は、BenchmarksでKPIが出ない理由 で詳しく確認しています。
Mobile Employee Service Portal（/mesp）
PC のブラウザ画面では、何も表示されない白紙の状態でした。名前のとおりモバイル端末での利用を前提にしたポータルで、PC の画面幅では中身が描かれません。
PCで真っ白になる原因は、/mesp をPCで開くと真っ白になる で確認済みです。
Performance Analyzer（/perf）
専用のホーム画面を持っていませんでした。開くと Service Portal のホームと同じ構成（検索欄・Request Something などのアイコン行・Current Status などのパネル）が出ます。ただし色が沈んだ、テーマの当たっていない見た目になります。標準ポータル一覧の管理画面でも、Performance Analyzer の Theme 列だけが「(empty)」でした。
専用ホームが無く /sp の index にフォールバックする挙動は、/perf に専用ホームは無い で確認済みです。
もう1つの系統（sys_ux_app_config）との違い
ここまでの Service Portal とは別に、sys_ux_app_config という系統が同時に動いています。この系統の中心にあるのが UI Builder です。
UI Builder は Web ユーザーインターフェースを構築するツールです。App Engine Studio が生成したワークスペースのページを構築する場合や、カスタムのWeb体験を構築する場合に使います（UI Builder）。
sys_ux_app_config の内訳
sys_ux_app_config には128件の画面定義が登録されています。内訳は次の2つに分かれます。
表の内容を文字でも書き出します。
担当者向けワークスペース（7件）：Service Operations Workspace／Platform Analytics workspace／Request App Workspace ほかです。担当者が日常業務で開きます。
管理画面・ビルダー類（121件）：UI Builder (internal)／NLU Workbench／Guided Tours／Advanced Dashboards ほかです。管理者・開発者が設定・構築時に開きます。
sys_ux_app_config を「管理者だけが使う裏側の設定」と捉えると誤解になります。128件のうち7件は、担当者が問い合わせ対応や運用監視のために毎日開くワークスペースです。同じ系統の中に、利用者が触る画面と、管理者しか触らない画面の両方が含まれています。
どちらを使うかの判断軸
読者がポータルを検討するときに迷うのは、「新しく作るべきか」「標準のどれかで足りるか」という判断です。まず正規の順番を書きます。
エンドユーザー向けの窓口が必要な場合：まず Employee Center（esc）で足りるかを確認します。問い合わせ・申請・ナレッジ検索は、既定の状態ですでに用意されています。
ナレッジや承認など特定の業務だけを切り出したい場合：Knowledge Portal や CAB Workbench のように、その業務に特化した標準ポータルがすでにあるかを確認します。
担当者が使う運用画面が必要な場合：sys_ux_app_config に、目的に合うワークスペースがすでに登録されていないかを確認します。Service Operations Workspace のように、標準で用意されている運用画面は少なくありません。
上記のどれにも当てはまらない場合に限り、Service Portal の新規ポータル作成、または UI Builder でのワークスペース新規作成を検討します。
標準ポータルの中には、名前だけでは動作が想像しにくいものも含まれます。Performance Analyzer は専用ホームを持たない構成になっていますし、Benchmarks はオプトイン設定をしないと指標が表示されません。Walk-up にいたっては、限定ロールを持つ専用アカウントでないと開けません。名前で判断せず、実際に開いて確認してから採用を決めます。
この4段階の順番を守ると、開発に着手する前に確認すべき範囲が絞り込めます。標準の画面で足りる部分と、追加開発が要る部分を早い段階で切り分けられるからです。
実機で気づいたこと
同じ4つの部品でも、ポータルごとに優先順位が違います。 Service Portal のホームは Current Status・My Open Incidents・My Approvals のように、自分の業務データを前面に出す作りです。Employee Center のホームは Popular topics・Recommended for you のように、コンテンツの発見を前面に出します。どちらも「検索・カタログ・ナレッジ・メニュー」という同じ部品構成なのに、優先して見せるものが違うと画面の印象は大きく変わります。ポータルを選ぶときは、部品の有無だけでなく、どの部品を先に見せているかも確認したほうがよいでしょう。
URL の id= パラメータは共通の呼び名にすぎません。 id=sc_home という同じ文字列で開いても、Service Portal では申請履歴、Employee Center では人気アイテムと、中身がまったく違いました。ポータル間で画面をコピーするような設計変更をするときは、id が同じだからといって同じページを指しているとは限らない点に注意が要ります。
Walk-up と Benchmarks は、止まって当然の設計でした。 どちらも「一般の管理者アカウントでは入れない」という結果でしたが、原因は不具合ではなく意図的な制限です。Walk-up は受付端末専用アカウント前提、Benchmarks はオプトインという契約に近い前提が要ります。標準ポータルを一覧で見て「10種類あるから全部試せる」と思っても、実際には利用条件が個別に設定されているものがある、という前提で臨んだほうがよいということです。
カテゴリを辿るより、検索のほうが確実でした。 カタログの Browse by Categories は Hardware カテゴリだけで9件あり、目的の商品は Show More を押さないと出てきません。ナレッジのカテゴリ行も、押すと画面は変わるのに一覧の中身は変わりませんでした。目的のレコードを1件だけ探すなら、カテゴリより先にヘッダーの検索を使うほうが早く見つかります。
検証範囲とおことわり
検証環境：Australia PDI / OOTB / 2026-09-22 確認
未確認のこと
各ポータルへの sp_instance 配置数の内訳（どのポータルに何件配置されているか）は確認していません。
sys_ux_app_config 128件のうち、管理画面・ビルダー類121件の全件の役割は確認していません。
トピック21件のうち、Risk and compliance 配下の子トピックの内訳は確認していません（Technology services 配下のみ内訳を確認しています）。
Employee Center のホーム画面は、直前に別のポータルを開いた直後だと表示が変わって見えることがありました。単体で開いた場合の構成を本文の記述として採用しています。
本記事は標準（OOTB）の構成を対象とし、カスタマイズを加えた環境での挙動は対象外です。既存の記事で独自に手を加えている場合は、この記事の内容とは一致しないことがあります。
これらは第2巻「ポータルモジュールの設定」で扱う予定です。第2巻では、9テーブルの積み上げとロール・プロパティ・連携を実測ベースで扱います。
用語集
Service Portal：ページ・ウィジェット・テーマを組み合わせて作る、標準のポータル基盤です。
Employee Center：Service Portal の既定ポータルで、部門横断の問い合わせ・申請窓口です。
UI Builder：ワークスペースやカスタム画面をコンポーネントの組み合わせで作るツールです。
Next Experience：UI Builder が使うコンポーネント群や画面基盤の総称です。
sys_ux_app_config：Next Experience / UI Builder 系の画面定義を保持するテーブルです。
sp_widget：ポータルに配置する機能部品（ウィジェット）の定義を保持するテーブルです。
sp_page：ポータルの画面1枚に対応する定義を保持するテーブルです。id は画面種別の呼び名で、実体のレコードはポータルごとに分かれます。
タクソノミー（taxonomy）：メニューの階層をトピック単位で管理する仕組みです。Employee Center のメガメニューはこの仕組みで構成されています。
トピック（topic）：タクソノミー配下の分類項目です。親を持たない最上位トピックと、その配下の子トピックの2段構成です。
調査で使ったURL
/sp_portal_list.do?sysparm_query=ORDERBYurl_suffix — 標準ポータル10件の一覧
/sp /esc /kb /swp /cab /sp_config /benchmarks /perf /mesp /walkup — 10ポータルのトップ画面
