Flow Designerの中身は3テーブル（sys_hub_flow）

2026年6月21日 22:32

ServiceNow では、「レコードが作られたら自動で承認を回す」「カタログ申請が来たらタスクを切る」といった自動化を組む場面が増えています。いまの中核になっているのが Flow Designer（Workflow Studio） です。画面上はドラッグ＆ドロップでフローを組むだけですが、その裏では Flow 定義・トリガ・アクションがそれぞれ別のテーブルに保存され、参照でつながっています。

この記事では、Flow Designer を機能論だけで説明しません。実際の sys_hub_flow（Flow 定義） を起点に、3つのテーブルの関係を扱います。いつ動くかを決めるのが sys_hub_trigger_instance（Trigger）、何をするかを並べるのが sys_hub_action_instance（Action）です。PDI（Zurich）の OOTB で確認した実測値とともに示します。

この記事は、ServiceNow の Incident や Change は触ったことがあるが、Flow Designer の裏側のテーブル構造をこれから理解したい人を想定しています。管理者・開発者が実機で確認するときに見るべきポイントは、Flow の階層とトリガの種別、アクションの数、そしてレガシー Workflow との関係です。以下、順番に確認します。

この記事で分かること

自動化の定義が sys_hub_flow（Flow） に保存され、type で Flow / SubFlow が分かれること
いつ動くかを決める sys_hub_trigger_instance が、flow と trigger_type を持つこと
何をするかを並べる sys_hub_action_instance が、flow に order 順でぶら下がること
トリガ種別（record_create / スケジュール / カタログなど）の実機での内訳
この PDI ではレガシー Workflow（wf_workflow）が 0 件で、自動化が Flow に一本化されていること
実機で確認するときに見るべき一覧 URL

この記事の内容は ServiceNow の PDI（Personal Developer Instance）Zurich（ズーリッヒ）リリースの OOTB（初期設定）で確認した個人メモです。本番環境やカスタマイズ済み環境では、フロー・フィールド・件数の内容が異なる場合があります。

Flow Designer（Workflow Studio）とは

Flow Designer とは、「いつ（トリガ）」「何を（アクション）」するかを、ノーコードのフローとして組み立てる自動化ツールです。Zurich では Workflow Studio という枠組みの中に置かれ、Flow・SubFlow・Action・Decision Table などをまとめて扱います。

その「フローの定義そのもの」を格納する中心テーブルが sys_hub_flow（画面上のラベルは Flow）です。今回確認した PDI（Zurich / OOTB）では、sys_hub_flow には338件の Flow 定義があり、うち active が303件でした。

Flow Designer の見た目は1枚のキャンバスです。ですが内部では、フロー定義・トリガ・アクションが別々のテーブルに分かれて保存されています。対応するテーブルは sys_hub_flow・sys_hub_trigger_instance・sys_hub_action_instance です。フローを調査するときは、この3テーブルをセットで見ることになります。

実際の Flow Designer のキャンバスを見ると、上にトリガ、下にアクションが order 順に並ぶ構造がそのまま画面に出ています。

Flow まわりの3テーブルの関係

Flow Designer に関係するテーブルは、大きく「フロー定義」「トリガ」「アクション」の3つに分けて見ると整理できます。

今回確認した PDI（Zurich / OOTB）では、それぞれ次の構造でした。

sys_hub_flow（Flow） … フロー定義そのもの。固有フィールドは13、レコードは338件（active 303）でした。
sys_hub_trigger_instance（Trigger Instance） … 「いつ動くか」。固有フィールドは18、レコードは103件でした。flow（→ Flow）で、どのフローのトリガかが決まります。
sys_hub_action_instance（Action Instance） … 「何をするか」。固有フィールドは5、レコードは1720件でした。flow で所属フローが決まり、action_type で実行する処理（例: Update Record）を指します。

つまり、1つの Flow に対して、トリガは基本1つ、アクションは複数（order 順）ぶら下がるという関係です。トリガが多くないのに対しアクションが1720件と多いのは、1フローが複数の処理ステップを持つからです。

3テーブルの基本は、次の表のとおりです。

テーブル定義は、次の URL で確認できます（先頭の <YourInstance> は自分のインスタンスに置き換えてください）。

https://<YourInstance>/sys_db_object_list.do?sysparm_query=name=sys_hub_flow^ORname=sys_hub_trigger_instance^ORname=sys_hub_action_instance

Flow の継承と type（Flow / SubFlow）

sys_hub_flow は単独のテーブルではなく、Application File 系のメタデータとして継承の上に成り立っています。

継承は sys_metadata まで3階層

今回確認した PDI（Zurich / OOTB）では、次の継承でした。

sys_hub_flow は sys_hub_flow_base（Flow Base）を継承します。さらにその親が sys_hub_flow_block（Flow Block）、その親が sys_metadata（Application File）です。name / active / description などは親の Flow Base 由来です。sys_hub_flow 固有はコンパイルやスナップショット管理用の内部フィールドが中心です。
sys_hub_trigger_instance は super_class が空のルート基底テーブルでした。task などは継承していません。
sys_hub_action_instance は sys_hub_flow_component（Component）を継承していました。

type=flow は89件、type=subflowは247件

sys_hub_flow には type フィールドがあります。今回の PDI では、type=flow（トリガで起動するメインフロー）が89件（active 62）、type=subflow（部品として他フローから呼ばれるサブフロー）が247件でした。

Flow 定義の多く（247/338）は、実は単体では起動せず他のフローから呼ばれる SubFlow です。「Flow が338件もある」と聞くと多く感じますが、トリガで自走するメインフローはそのうち89件です。SubFlow の呼び出し関係は sys_hub_sub_flow_instance（今回116件）に記録されます。

公式の Flow Designer architecture overview（Zurich）に、Flow・SubFlow・Action といった Workflow Studio の構成要素の関係が説明されています。

トリガ：いつ動くか（trigger_type）

フローが「いつ動くか」を決めるのが sys_hub_trigger_instance です。1つの Flow に対して基本1つ紐づき、trigger_type でどんなきっかけかを表します。

レコード系トリガが78件で中心

今回確認した PDI（Zurich / OOTB）で、トリガ全 103 件を trigger_type で集計すると、次の内訳でした。

中心になるのは レコード系トリガです。record_create（作成時, 33）／ record_create_or_update（作成・更新時, 29）／ record_update（更新時, 16）の合計78件が大半を占めました。残りは Service Catalog（7）・SLA Task（6）、スケジュール系は weekly（4）・daily（2）・repeat（2）・run_once（2）、Inbound Email（2）でした。sys_hub_trigger_instance は trigger_inputs / trigger_outputs というフィールドも持ち、トリガ自体の入出力値もレコードとして保持します。

マスタは16種、実際に使われるのは10種

トリガの種別マスタにあたる sys_hub_trigger_definition は、今回16種あります。大別すると3系統です。まず「レコード変更」。次に「スケジュール（Daily / Weekly / Monthly / Recurrence …）」。そして「アプリ起点（Service Catalog / SLA Task / Inbound Email / Knowledge Management …）」です。

実機に存在するトリガ（103件）は、マスタの16種すべてを使っているわけではありません。OOTB の Flow が実際に使っているのは10種で、Monthly・Recurrence・Knowledge Management・Proactive Analytics・Remote Table Query・Trigger Rest の6種はマスタに定義があるだけで、今回のインスタンスでは使われていませんでした。

実際のトリガ一覧を見ると、Flow ごとに Trigger definition と Trigger type が並び、どのフローが何で起動するかが横並びで読み取れます。

トリガ一覧は、次の URL で確認できます。

https://<YourInstance>/sys_hub_trigger_instance_list.do?sysparm_query=ORDERBYtrigger_type

公式の Flow trigger types（Zurich）に、レコード・スケジュール・アプリ起点といったトリガ種別の一覧と挙動が説明されています。

アクション：何をするか（action_type）

フローが「何をするか」を表すのが sys_hub_action_instance です。1つの Flow に複数のアクションが order 順にぶら下がり、それぞれ action_type で実行する処理を指します。

アクション本体1720件に対し定義のカタログは478種

今回確認した PDI（Zurich / OOTB）では、アクションインスタンスは1720件ありました。action_type は sys_hub_action_type_base（アクション定義・部品） を参照します。実レコードでは「Update Record」「Send Notification」といった定義に紐づいていました。

アクション定義そのもの（部品の側）はさらに多いです。sys_hub_action_type_base が1075件、有効なアクション種別 sys_hub_action_type_definition（active）が478件ありました。つまり、Flow に配置された個々のアクション（1720）の裏に、再利用可能なアクション定義（478種〜）のカタログがあるという二層構造です。sys_hub_action_instance 側は action_inputs フィールドで、各アクションの入力値レコード（Action Input）とつながっています。

アクションの一覧を見ると、各レコードが flow と action_type を持ち、どのフローのどの処理かが分かります。

アクション一覧は、次の URL で確認できます。

https://<YourInstance>/sys_hub_action_instance_list.do?sysparm_query=ORDERBYDESCsys_created_on

なお、IF や FOR EACH といった分岐・繰り返しは「アクション」ではなく Flow Logic（sys_hub_flow_logic, 今回2226件） として別に保存されます。その定義種別にあたる sys_hub_flow_logic_definition は26種でした。フローのステップは「アクション」「フローロジック」「サブフロー呼び出し」の3種が混在して並ぶ、と理解しておくと調査が楽です。

公式の Flow Designer actions（Zurich）に、Create Record / Update Record / Send Email などの標準アクションが一覧で説明されています。

トリガからアクションへ：実行の流れ

ここからは、この3テーブルが実行時にどうつながるかを示します。

今回確認した PDI（Zurich / OOTB）では、フローが実際に走った履歴を表す sys_flow_context が8350件ありました。これは「Flow 定義（338件）が、これまで延べ8350回実行された」ことを示します。

ポイントは、sys_hub_flow / trigger / action は「設計図」、sys_flow_context は「実行ログ」だという区別です。フローが期待どおり動かないとき、設計（3テーブル）を見るか、実行履歴（context）を見るかで調査の入り口が変わります。

レガシー Workflow は0件、Flow Designerに一本化

そして見逃せないのが、レガシー Workflow との関係です。今回の PDI では、旧 Workflow の定義テーブル wf_workflow が 0 件でした（published も 0）。

少なくとも今回確認した PDI（Zurich / OOTB）では、自動化が Flow Designer に一本化されており、旧 Workflow 由来の定義は存在しません。Flow Designer が Workflow の後継として中核を担っている、という位置づけが件数からも裏づけられます。実環境では、過去に作られた wf_workflow が残っていることもあるため、移行状況は wf_workflow の件数で確認するのが確実です。

公式の Create a flow in Workflow Studio（Zurich）に、トリガとアクションを組み合わせてフローを新規作成する手順が説明されています。

Flow Designer まわりの構成要素

Flow の動きは、フロー定義だけでは決まりません。アクションの入力値・フローロジック・サブフロー呼び出しなど、複数の構成要素が組み合わさって1つのフローを形作ります。

今回確認した PDI（Zurich / OOTB・2026-06-20 確認）では、次のような構成要素が存在していました。

構成要素の件数（Action Input・Flow Logic ほか）

特徴的なのは Action Input が 3295 件と、アクション本体（1720）より多いことです。1つのアクションが複数の入力値（更新先テーブル・更新フィールド・通知先など）を持つため、入力値の総数のほうが多くなります。フローの実体は「アクションの並び」だけでなく「各アクションへの入力値の束」でできている、と捉えると、フローのエクスポートやコピーで何が運ばれるかが見えてきます。

注意したいのは、ここで数えているのは Flow Designer の構成テーブルだけという点です。実際のフローの挙動は、トリガ条件（filter）の評価や、アクションが裏で呼ぶスクリプトとも合わさって決まります。テーブル件数だけでフロー全体を判断しないようにします。

自分のインスタンスでは、次の URL で各一覧を開けます（先頭の <YourInstance> は置き換えてください）。

Flow 一覧        : https://<YourInstance>/sys_hub_flow_list.do?sysparm_query=active=true
トリガ一覧       : https://<YourInstance>/sys_hub_trigger_instance_list.do
アクション一覧    : https://<YourInstance>/sys_hub_action_instance_list.do
実行コンテキスト  : https://<YourInstance>/sys_flow_context_list.do

ServiceNow における Flow Designer のポイント

自動化の定義は sys_hub_flow（Flow） に保存されます。今回の PDI では 338 件、うち active 303 件、type=flow 89 / subflow 247 でした。
sys_hub_flow は sys_hub_flow_base → flow_block → sys_metadata を継承する Application File 系メタデータです。固有フィールドは13でした。トリガはルート基底、アクションは Component 継承です。
「いつ動くか」は sys_hub_trigger_instance（103件） が flow と trigger_type で決めます。レコード系（create / create_or_update / update）が78件で大半でした。
「何をするか」は sys_hub_action_instance（1720件） が flow に order 順でぶら下がります。action_type で標準アクション（Update Record 等）を指します。IF / FOR EACH は Flow Logic（2226件）として別管理です。
フローが走った履歴は sys_flow_context（8350件） に残り、設計（3テーブル）と実行ログは別物です。
レガシー Workflow（wf_workflow）は 0 件で、この PDI では自動化が Flow Designer に一本化されていました。

フローを調べるときは、まず「このフローは何で起動し（trigger_type）、何を順に実行するか（action の order）」を読みます。そのうえで、Flow 定義単体ではなく、上のトリガ・下のアクション・横のサブフロー・実行履歴（context）をセットで見ることが重要です。

実機で気づいたこと

Flow 定義（sys_hub_flow）は338件あるのに、トリガで自走する type=flow はそのうち89件だけでした。残り247件は SubFlow として他フローから呼ばれる部品です。件数だけを見ると「Flowが338本もある」と身構えますが、実際に自分で調べる起点になるのは1/4程度だと分かると、調査の当たりを付けやすくなります。
sys_hub_trigger_instance だけ super_class が空のルート基底テーブルで、Flow や Action のように sys_metadata を継承していませんでした。Flow・Action はどちらも Application File 系の継承ツリーに乗っているので、最初は3テーブルとも同じ系列だと思い込んでいましたが、トリガだけ独立した作りになっています。トリガ定義は Flow 本体より先に評価される性質上、あえて Application File の枠外に置かれているのではないか、というのが実機を見た印象です（推測）。
トリガ種別マスタは16種類あるのに、このPDIで実際に使われていたのは10種でした。Monthly や Proactive Analytics、Remote Table Query のような種別は用意されているだけで一度も使われておらず、OOTBのデモデータは「機能をひととおり見せる」よりも「よく使う型に絞って作られている」ように見えました。

次に読むなら

次に確認するなら、トリガの条件（どのテーブルの・どんな filter で起動するか）の指定方法です。加えて、Action Designer でのカスタムアクションの作り方、サブフローによるフローの部品化もあります。特に「トリガで自走するメインフロー（type=flow）」と「部品として呼ばれる SubFlow（type=subflow）」を分けて理解すると、調査の見通しがよくなります。フローが動かないときに『どのフローから追えばいいか』が一気に絞れます。これらは本記事の「Flow の type」「トリガ」「アクション」で触れた仕組みの先にあたり、別記事で解説する予定です。

用語

PDI：Personal Developer Instance（無料の検証用インスタンス）
OOTB：Out of the Box（初期設定のまま）
Flow（sys_hub_flow）：自動化の定義そのもの（Flow / SubFlow）
Trigger（sys_hub_trigger_instance）：フローを起動するきっかけの定義
Action（sys_hub_action_instance）：フロー内で実行する1つの処理
SubFlow：他フローから部品として呼ばれるフロー（type=subflow）
Flow Context（sys_flow_context）：フローが実行された履歴

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

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

テーブル定義       : sys_db_object_list.do?sysparm_query=name=sys_hub_flow^ORname=sys_hub_trigger_instance^ORname=sys_hub_action_instance
Flow フィールド一覧 : sys_dictionary_list.do?sysparm_query=name=sys_hub_flow^elementISNOTEMPTY
Flow 一覧          : sys_hub_flow_list.do?sysparm_query=active=true^ORDERBYtype
トリガ一覧         : sys_hub_trigger_instance_list.do?sysparm_query=ORDERBYtrigger_type
アクション一覧      : sys_hub_action_instance_list.do?sysparm_query=ORDERBYDESCsys_created_on
実行コンテキスト    : sys_flow_context_list.do

検証範囲とおことわり

確認した範囲：sys_hub_flow / sys_hub_trigger_instance / sys_hub_action_instance の階層、固有フィールド数（flow 13 / trigger 18 / action 5）、レコード件数（flow 338・active 303、type別 flow 89/subflow 247、trigger 103、action 1720、context 8350、wf_workflow 0）、trigger_type の内訳（全103件）、トリガ種別マスタ16種、主要フィールドと参照先、構成要素の件数。すべて PDI（Zurich / 2026-06-20 確認）の OOTB で取得しています。
確認していない範囲（断定しません）：各 Flow の中身（ステップ順序・条件式）、トリガ条件（filter）の評価タイミング、アクションが裏で呼ぶスクリプトの挙動、Flow 実行エンジンの内部、Action Designer でのカスタムアクション作成、Decision Table / Playbook など Workflow Studio の他機能、本番でのカスタムフロー。これらは別記事で扱います。

今回は PDI の OOTB（初期設定）を前提に、Flow Designer の構造を確認しました。実環境では、既存のカスタマイズや過去の Workflow 移行状況によって、フローやフィールド・件数が変わります。