ServiceNowのワークスペースは従来のフォームと何が違う？ どちらを直せば画面が変わるのか
「ワークスペースのボタンを直したのに、従来のフォームには反映されない」「逆に、従来UIでUI Actionを直したのにワークスペースには出てこない」。ServiceNowを触っていると、この2つの画面がどう関係しているのか分からなくなる瞬間があります。結論は、フォームとワークスペースは最初から別のテーブル系列で動いていて、直すボタンも直す場所も別だということです。Service Operations Workspaceを実機で分解し、同じIncidentレコードを両方の画面で開いて、どこまでが別物でどこだけがつながっているのかを確認しました。
検証環境：Zurich PDI / OOTB / 2026-08-09 確認
結論：3つの分かれ目
ワークスペースの画面は sys_ux_app_config → sys_ux_app_route → sys_ux_screen_type → sys_ux_macroponent という4段階で組み立てられています。従来UIの sys_ui_form / sys_ui_section / sys_ui_element とは参照関係のない、まったく別のテーブル系列でした
フォーム上のボタンも同じです。従来UIは sys_ui_action（incidentで29件）、ワークスペースは sys_declarative_action_assignment（incidentで38件）が担当します。同じ「Resolve」というラベルのボタンが両方にありますが、中身は別レコードで、一方を直しても他方には響きません
唯一の橋は format_for_configurable_workspace というフラグです。ただしincidentの29件中trueは7件だけで、Resolveはそこに含まれていません。多くのボタンは橋を渡らず、テーブルごとに作り直されています
上から見ると、1件のレコードを開いた瞬間に道が2つに分かれます。左のワークスペース側は4段階の設定を経て画面になり、右の従来UI側は3段階のフォーム構造とボタンのテーブルで画面になります。両者を結ぶ線は1本だけで、しかもその線を通れるボタンはごく一部です。以下、この図の各段を実機のレコードで裏付けていきます。
ワークスペースの画面はどう組み立てられているか
sys_ux_app_config：ワークスペースそのものの設定
ワークスペースという単位そのものを持つテーブルが sys_ux_app_config です。全体では120件登録されています。名前に「Workspace」を含むレコードを探すと、6件が見つかりました。
Platform Analytics workspace
Service Operations Workspace
Request App Workspace
Creator Studio Workspace
Asset Workspace App Config
CMDB Workspace App Config
Service Operations Workspaceのレコード自体は、名前・説明・アイコン・Landing Path（ログイン後に開く最初のパス、既定はhome）だけを持つ、思いのほかシンプルな作りでした。実体を作っているのは、この下にぶら下がる関連レコード群です。画面の関連タブには「UX App Routes（top-level）66」「Ux Screens（top-level）69」「Themes 1」と表示されています。これは直下のレコードだけを数えた値です。ネストした子ルートまで含めると、UX App Routesは205件に増えます。数え方によって見える件数が変わる点は、後ほど気づいたことの節でも触れます。
sys_ux_app_route：URLと画面をつなぐ1本のルート
/now/sow/record/incident/... のような画面のURLを受け止めるのが sys_ux_app_route です。Service Operations Workspaceに紐づくルートを見ると、route_type が record のレコードはちょうど1件でした。
つまりincidentもproblemもchange_requestも、URLの見た目は違っても、裏側では同じ1本のrecordルートを共有しています。テーブルごとに専用のルートを用意する設計ではありません。このルートが指す先が sys_ux_screen_type の「Record」というレコードで、こちらも sys_package: Service Operations Workspace Core に属する共通の画面コレクションでした。
sys_ux_screen_typeとsys_ux_macroponent：テーブルごとの中身
「Record」という共通の画面コレクション自体は、名前と説明くらいしか持たない骨組みです。テーブルごとの見た目を実際に持つのは sys_ux_macroponent（部品ツリーの定義、全体で3,383件）でした。名前に「Incident」を含む macroponent を探すと「Incident Overview」が2件ヒットします。ここに画面のレイアウトを表すJSON列（composition / layout）が入っており、フィールドや関連リストの配置はこのJSONの中で決まっている構造です。
sys_ux_macroponentの項目一覧にはextends（継承元）・props（受け取る値）・interactions（操作の受け口）・handled_events（受け取るイベント）といった列名も並んでいました。フォーム1枚が単発のレコードで完結するsys_ui_formと違い、部品を継承・合成して組み立てる作りであることが列名からもうかがえます。
骨組みはsys_ux_app_config → sys_ux_app_route → sys_ux_screen_typeという3段でテーブル共通、最後のsys_ux_macroponentだけがテーブル固有という組み方でした。従来UIのsys_ui_formがテーブルごとに1件ずつ存在するのと比べると、ワークスペースは「共通の骨組み＋テーブル別の部品ツリー」という発想の違いが見えます。
同じINC0000015を2つの画面で並べる
VPNクライアントが起動しないというIncident（INC0000015）を、従来フォームとワークスペースの両方で開いて比べました。
同じレコードなのに、画面の作りはかなり違います。従来フォームは項目を上から並べる一段組みですが、ワークスペースは中央にカード、右にActivityと関連情報パネルという3カラム構成です。ボタンの並びも、従来UIはFollow・Update・Resolve・Delete、ワークスペースはSave・Create change request・Resolveと一部だけ重なります。ワークスペースのホーム画面（/now/sow/home）を開くと、さらに違いがはっきりします。
従来UIの左メニュー（Application Navigator）は一覧型のツリーですが、ワークスペースの左はアイコンだけの細い列で、中央にウィジェット型のダッシュボードが並びます。ナビゲーションの仕組みそのものが別物という印象です。
タブの構成も違います。従来フォームのタブはNotes・Related Records・Resolution Informationのように、そのテーブル特有の項目名が並びます。ワークスペースのタブはOverview・Details・Related recordsと、どのテーブルでもほぼ共通の名前になっていました。これも、テーブル共通の骨組みにテーブル別の部品を差し込むという、先ほどのsys_ux_macroponentの構造と合っています。
Resolveボタンは同じ名前でも別レコードだった
見た目の違いより気になったのは、両方の画面に「Resolve」ボタンがあることです。ラベルが同じなら中身も同じかと思い、両方のレコードを開いて突き合わせました。
従来UI側のResolve
従来UIのResolveはsys_ui_actionのレコードで、Applicationはグローバル、onclickにresolveIncident();、スクリプトの中身はg_form.setValue('incident_state', 6)のような素直なクライアントスクリプトでした。
ワークスペース側のResolve
一方ワークスペースのResolveはsys_declarative_action_assignmentのレコードで、所属アプリケーションはIncident Management for Service Operations Workspaceという専用のスコープアプリです。実装方式は「UXF Client Action」、呼び出す先はSOW Incident Resolve V2という別テーブル（sys_declarative_action_payload_definition）のペイロード定義でした。
sys_declarative_action_assignmentのaction列自体も、参照先はsys_ui_actionではなくsys_declarative_action_definitionという専用テーブル（全体で16件）です。つまりワークスペースのボタンは設計の出発点からsys_ui_actionと切り離されています。ラベルが「Resolve」で一致しているのは偶然ではなく、開発チームが手作業で同じ名前を付けた結果です。
incidentテーブルのsys_declarative_action_assignmentは38件でした。実装方式の内訳は次の画面の通りです。
唯一の橋：format_for_configurable_workspaceフラグ
完全に無関係というわけでもありません。sys_ui_actionにはformat_for_configurable_workspaceという真偽値の列があります。これがオンのUI Actionだけは、ワークスペース側にも顔を出す仕組みが用意されています。ただしオンになっているのは全体2,484件中72件、incidentの29件中では7件だけでした。7件の内訳は次の通りです。
Create Incident Task
Copy Incident
Create child incident
Create Knowledge
Close（フォームボタンとして表示される唯一の項目）
Report Knowledge Gap
Resolveはこの7件に含まれていません。橋は用意されているのに、いちばん使われそうなボタンほど橋を渡らず作り直されている、というのが実機で見えた実態でした。
フォームレイアウトを直してもワークスペースは変わらない
項目の並び順についても同じ関係が成り立ちます。従来UIの並びはsys_ui_form・sys_ui_section・sys_ui_elementという3段構造（incidentでそれぞれ8件・44件・355件、詳しくは画面・フォームの完全ガイドで扱っています）が持ちますが、ワークスペースの並びはsys_ux_macroponentのcompositionというJSON列が持ちます。両者の間に参照関係を示す列は見つかりませんでした。従来のForm Layoutでフィールドの位置を入れ替えても、ワークスペースの画面は動かないと考えられます。この逆方向についても同様で、ワークスペース側の並びを変える操作は、従来フォームには影響しません。
実機で気づいたこと
いちばん意外だったのは、Resolveという最重要ボタンほど橋を渡っていなかった点です。CloseやCreate Incident Taskのような周辺的なアクションは、フラグ経由で両方に出せます。業務の中心であるResolveだけは、専用のスコープアプリで一から作り直されていました。おそらくResolveは状態遷移・必須項目チェック・確認ダイアログといった業務ロジックが重いのだと思います。単純なフラグで両画面に出し分けるより、ワークスペース向けに設計し直したほうが結局は保守しやすいという判断だったのでしょう。
もう一つの発見は、sys_declarative_action_definitionが16件しかないのに、sys_declarative_action_assignmentは全体で697件もある点です。definitionは「UXF Client Action」「Server Script」のような実装方式のテンプレートで、assignmentがそれをテーブルごと・ボタンごとに割り当てる構造でした。少数の型を大量のテーブルで使い回す設計で、これはsys_ui_actionが1レコード1ボタンで完結する従来の作り方とは発想が違います。
sys_ux_app_configの関連タブに出ていた「UX App Routes 66」と、REST集計で数えた205という数字が食い違ったのも実機ならではの気づきでした。画面の関連タブは直下のルートだけを数え、REST側は入れ子になった子ルートまで含めて数えます。同じテーブルを見ていても、数え方次第で見える件数が3倍近く変わることがあると分かりました。
どちらを直せばいいか：対応表
これまでの内容を、直したい対象ごとに整理しました。
見て分かる通り、ワークスペース列と従来UI列はほぼすべての行で別のテーブルを指しています。「これを直せば両方に効く」という設定は、実質的にformat_for_configurable_workspaceフラグの一部のボタンだけでした。
改修依頼を受けたときは、まず利用者がどちらの画面を見ているかを確認します。「Incidentのボタンを直してほしい」という依頼だけでは、sys_ui_actionとsys_declarative_action_assignmentのどちらを直すべきか決まりません。画面のURLが/now/sow/から始まっているかどうかを見れば、対象のテーブルを一発で絞り込めます。
実務でつまずきやすい点
ワークスペースで新しいボタンを追加したのに従来フォームに出てこない、あるいはその逆は、仕様通りの動きです。両方に出したい場合は、それぞれのテーブルに個別のレコードを作る必要があります
従来UIのUI Actionを無効化しても、ワークスペースの同名ボタンは消えません。障害調査でボタンが消えたと報告を受けたら、まずどちらの画面での話かを確認してからテーブルを特定します
Form Layoutでフィールドの並びを変えても、ワークスペースの画面には反映されません。ワークスペースの見た目を変えるにはUI Builder側の編集が必要です（今回は編集作業までは検証していません）
sys_ux_app_configの関連タブに出る件数は「直下のみ」です。全体の規模を知りたいときはREST側かリストビューでapp_config列を条件にした件数を確認します
Service Operations Workspaceの一覧メニュー構成はsys_ux_list_menu_configの「Default - SOW」レコードが持ちます。一覧の並びを調整したいときはここが起点になりますが、中身の詳細は今回未検証です
「ワークスペースにボタンが無い」という相談を受けたら、まずsys_declarative_action_assignmentをtable列で絞り込みます。sys_ui_action側だけを見て「設定されているはずなのに出ない」と悩む時間を減らせます
スコープアプリの切り替え表示（「このレコードは○○アプリケーションに属しています」という案内）は、ワークスペース関連のレコードを開くとほぼ毎回出てきます。編集前にどのアプリケーションのレコードかを確認する癖をつけておくと安全です
よくある質問
Q1. ワークスペースで作ったボタンを従来フォームにも出したいときはどうしますか
ワークスペース側のsys_declarative_action_assignmentとは別に、従来UI側でsys_ui_actionを新規に作成します。参照関係が無いため、片方を作るだけではもう片方に反映されません。
Q2. format_for_configurable_workspaceフラグをオンにすれば、既存のUI Actionはワークスペースに出ますか
フラグが対応する範囲であれば表示される可能性はありますが、今回の検証では実際に画面上のどこに表示されるかまでは確認していません。Resolveのように業務ロジックが重いボタンは、フラグに頼らず専用の宣言的アクションとして作り直されている例が実機にありました。
Q3. Form Layoutを直したのにワークスペースの並びが変わりません。なぜですか
Form Layout（sys_ui_form/sys_ui_section/sys_ui_element）とワークスペースの画面（sys_ux_macroponent）は別のテーブル系列だからです。ワークスペースの並びを変えたい場合はUI Builder側の編集が必要になります。
Q4. 従来UIとワークスペース、どちらを優先して設計すればよいですか
利用者がどちらの画面を主に使うかで決めます。エージェントが日常的にワークスペースを使う運用であれば、ボタンや画面の変更もワークスペース側を主軸にし、従来UI側は必要な範囲だけ揃えるのが手戻りが少ない進め方です。
Q5. ワークスペースの画面がどのレコードで定義されているか、どこから調べ始めればよいですか
sys_ux_app_configでワークスペース名から辿り、関連するsys_ux_app_routeでroute_typeを確認し、screen_typeが指すsys_ux_macroponentのcomposition列を見ます。今回の検証ではこの4段階までは追えましたが、composition列のJSON内部は未展開です。
まとめ
従来UIとワークスペースは、見た目が似ていても土台となるテーブルが別です。フォームはsys_ui_form系列、ワークスペースはsys_ux_app_configからsys_ux_macroponentまでの4段階という別系列で組み立てられています。ボタンも同様に、sys_ui_actionとsys_declarative_action_assignmentは別系列です。Resolveのように同じラベルを持つボタンでも、実体は別レコードでした。唯一の橋であるformat_for_configurable_workspaceフラグも、対象はincidentの29件中7件だけです。業務の中心となるボタンほど、個別に作り直されているのが実機で見えた姿でした。片方の画面で設定を変えても、もう片方には無関係だと考えて設計する必要があります。
用語
sys_ux_app_config … ワークスペースそのものの設定を持つテーブル（Service Operations Workspaceなど）
sys_ux_app_route … URLと画面（screen_type）を結び付けるルート定義
sys_ux_screen_type / sys_ux_macroponent … 画面コレクション（テーブル共通）と部品ツリー（テーブル別）
sys_declarative_action_assignment / sys_declarative_action_definition … ワークスペースのボタン割り当てと、その実装方式のテンプレート
format_for_configurable_workspace … sys_ui_actionが持つ真偽値。オンのボタンだけがConfigurable Workspace側にも表示対象になる
実機で確認したURL
/now/sow/home … Service Operations Workspaceのホーム画面
/now/sow/record/incident/<sys_id> … Incident 1件をワークスペースで開く画面
/sys_ux_app_config.do?sysparm_query=nameLIKEWorkspace … ワークスペース関連のapp_config一覧
/sys_ux_app_route_list.do?sysparm_query=app_config=<sys_id> … 特定ワークスペースに紐づくルート一覧
/sys_declarative_action_assignment_list.do?sysparm_query=table=incident … incidentのボタン割り当て一覧
/sys_ui_action_list.do?sysparm_query=table=incident^format_for_configurable_workspace=true … 橋渡し対象のUI Action一覧
参考リンク
関連記事
検証環境と未検証範囲
件数はZurich PDI（OOTB）で確認したものです。テーブル同士の集計とREST集計を突き合わせており、推定やサンプリングではありません。
未読の範囲もあります。sys_ux_macroponentのcomposition/layoutJSON列の中身、つまりフィールドと画面部品の対応関係の詳細は今回展開していません。format_for_configurable_workspaceフラグがオンのUI Actionが実際にワークスペース画面上のどこ（ボタン列か、その他メニューか）に表示されるかも未確認です。Form Layoutを実際に変更してワークスペース側が変わらないことを再撮影する検証は、PDIへの書き込みを伴うため今回は行っていません。sys_ux_page_registryとsys_ux_list_menu_config配下の詳細な子テーブル構造も検証範囲外です。本番環境やカスタマイズ済みの環境では、テーブルの件数や橋渡し対象のボタンの構成が変わります。数字は環境ごとに違っても、フォームとワークスペースが別テーブル系列で組み立てられている構造そのものは共通です。
