レガシーWorkflow（wf_workflow）とFlowの違い

2026年6月22日 20:17

ServiceNow で自動化を組むなら、いまは Flow Designer（Workflow Studio）を使います。ところがドキュメントや古い実装には「ワークフロー（Workflow Editor）」「wf_workflow」「アクティビティ」という言葉が出てきます。Flow とどう違うのか、テーブルがどこにあるのかが見えにくくなります。

この記事は、Flow Designer の前の世代にあたるレガシー Workflow を、実テーブルから確認します。軸になるのは次の3つです。

定義を入れる wf_workflow（Workflow）
1つ1つの処理を表す wf_activity（Workflow Activity）
走った履歴を残す wf_context（Workflow context）

PDI（Zurich）の OOTB で確認した件数とフィールドを並べます。

対象読者は、Incident や Change は触ったことがあり Flow Designer も知っているが、その前のワークフロー機能が何だったのかをテーブル構造から押さえたい管理者・開発者です。

この記事で分かること

レガシー Workflow の定義は wf_workflow に入り、Flow と同じく sys_metadata 系メタデータであること
1つ1つの処理は wf_activity で、wf_workflow 直下ではなく版（wf_workflow_version）にぶら下がること
実行履歴は wf_context に残り、状態が executing / finished / faulted / cancelled で表されること
この PDI では wf_workflow / wf_activity / wf_context がすべて 0 件だったこと。活動の種類カタログ（wf_activity_definition）だけは 41 件 OOTB 同梱だったこと
Zurich で新規インスタンスに OOTB レガシー Workflow が同梱されなくなった、という公式の位置づけ
実機で確認するときに見るべき一覧 URL

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

レガシー Workflow（Workflow Editor）とは

レガシー Workflow は、アクティビティ（活動）を線でつないでフローを描くグラフィカルな自動化エンジンです。Approval（承認）・Timer（タイマー）・Run Script（スクリプト実行）といった部品をキャンバスに並べ、条件分岐や承認を組み立てます。Flow Designer が登場する前は、Change や Service Catalog の承認・タスク生成の多くをこの Workflow で組んでいました。

ワークフローの定義そのものを格納する中心テーブルが wf_workflow（画面上のラベルは Workflow）です。

今回確認した PDI（Zurich / OOTB）では、その wf_workflow が 0 件でした。レガシーワークフローの定義が1本も入っていません。

これは壊れているのではありません。Zurich から新規にプロビジョニングされるインスタンスには OOTB のレガシー Workflow が同梱されなくなった、という ServiceNow の方針と一致します。自動化は Flow Designer 側（sys_hub_flow）に移っており、同じ PDI で sys_hub_flow は 338 件ありました。

箱（テーブル構造）と部品カタログは OOTB に残っているのに、中身（実際のワークフロー）は空です。構造を追うには、定義0件・履歴0件・活動定義41件というこの状態を前提に読む必要があります。

レガシー Workflow まわりのテーブルの関係

レガシー Workflow に関係するテーブルは、定義・版・活動・種類カタログ・実行履歴の5つに分けると整理できます。

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

wf_workflow（Workflow）… ワークフロー定義そのもの。固有フィールド 10、レコード 0 件。
wf_workflow_version（Workflow Version）… 定義の版。チェックアウト／公開のたびに版が作られ、活動はこの版にぶら下がる。今回 0 件。
wf_activity（Workflow Activity）… 1つ1つの活動。固有フィールド 26、0 件。workflow_version（→ 版）で所属が決まり、activity_definition で種類を指す。
wf_activity_definition（Activity Definition）… 活動の種類カタログ。固有フィールド 5、41 件（唯一レコードが入っているテーブル）。
wf_context（Workflow context）… 実行履歴。固有フィールド 39、0 件。workflow と workflow_version でどの定義のどの版が走ったかを持つ。

ここで wf_activity は wf_workflow に直接ぶら下がらず、間に wf_workflow_version（版）を挟みます。これが Flow Designer との違いの1つで、レガシー Workflow はチェックアウト → 編集 → 公開という版管理を前提に設計されているためです。

3テーブル（＋関連2つ）の基本は、次の表のとおりです。

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

https://<YourInstance>/sys_db_object_list.do?sysparm_query=name=wf_workflow^ORname=wf_activity^ORname=wf_context^ORname=wf_activity_definition

継承：wf_workflow は Flow と同じ sys_metadata 系

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

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

wf_workflow → sys_metadata（Application File）。スコープに属する設計物として管理されます。Flow Designer の sys_hub_flow も同じ sys_metadata 系で、ワークフロー定義をメタデータとして扱う設計は世代をまたいで共通です。
wf_activity_definition → wf_element_definition → sys_metadata。活動の種類カタログもメタデータです。
wf_workflow_version / wf_activity / wf_context は super_class が空のルート基底テーブルでした。版・活動・実行履歴は、それぞれ独立した実体テーブルです。

つまり定義（wf_workflow）と種類カタログ（wf_activity_definition）はメタデータ（設計物）、版・活動・実行履歴は実データ、という分かれ方です。メタデータ側はスコープ管理・更新セットの対象になり、実データ側はインスタンス内のレコードとして増減します。

公式ドキュメントに、レガシー Workflow をグラフィカルに編集するエディタの位置づけが説明されています。

参考：Workflow editor（Zurich）

活動の種類カタログ：wf_activity_definition の41件

wf_workflow が空でも、レコードが入っていた唯一のテーブルが wf_activity_definition（活動の種類カタログ）の 41 件です。どんな活動を組めるかという部品リストで、Workflow が空でも OOTB に同梱されています。

今回確認した PDI（Zurich / OOTB）で、41件を category で集計すると、次の内訳でした。

最も多い Utilities（12）には、Begin / End / Run Script / Set Values / Branch / Join といった流れの制御が並びます。次いで Approvals（7）が多く、Approval - User / Approval - Group / Approval Action など承認系の活動が揃います。レガシー Workflow が承認プロセスの定番だった名残です。

Deprecated（6）には Subflow / Run Workflow / SOAP Message / REST Message などが入ります。役割を Flow Designer 側に譲って非推奨になった活動です。活動カタログを見るだけでも、レガシー Workflow から Flow Designer への移行の跡が読み取れます。

活動定義の一覧では、各活動の名前・対象テーブル・説明が並び、Approval - Group がどう承認レコードを生成するかまでカタログに書かれています。

活動定義の一覧は、次の URL で確認できます。

https://<YourInstance>/wf_activity_definition_list.do?sysparm_query=ORDERBYcategory^ORDERBYname

なお、活動定義のフィールド構成は、wf_activity 側の辞書を見ると掴みやすくなります。

公式ドキュメントに、アクティビティを並べてワークフローを新規作成する手順が説明されています。

参考：Create a workflow（Zurich）

実行履歴：wf_context と状態（state）

ワークフローが走ると、その1回ごとの実行が wf_context（Workflow context）に記録されます。Flow Designer の sys_flow_context に相当する実行ログです。

wf_context は固有フィールド 39 を持ち、定義側の wf_workflow（10）よりはるかに多くなります。実行時のステージ・起動者・状態など、ランタイムの情報を抱えるためです。workflow（→ wf_workflow）と workflow_version（→ 版）で、どの定義のどの版が走ったかを持ちます。started_by（→ sys_user）で誰が起動したかも持ちます。

実行の状態は state フィールドで表され、今回の選択肢は次の4つでした。

executing（Executing, 実行中）… ワークフローが走行中
finished（Finished, 完了）… 正常終了
faulted（Error, エラー）… 異常終了
cancelled（Cancelled, キャンセル）… 中断

wf_workflow / wf_activity が設計図、wf_context が実行ログという区別です。Flow Designer（設計＝sys_hub_flow、実行＝sys_flow_context）と同じ二層構造です。

今回の PDI では wf_context も 0 件でした。ワークフロー定義が1本もないので、走った履歴もありません。state の実レコードでの分布は検証範囲外です（選択肢の存在は確認済み）。

レガシー Workflow と Flow Designer の対応

ここまでの構造を現行の Flow Designer と並べると、両者が同じ役割を別テーブルで担うことが見えます。

今回確認した PDI（Zurich / OOTB）での件数を並べると、次の対応になります。

定義：wf_workflow（0）↔ sys_hub_flow（338）
1つの処理ステップ：wf_activity（0）↔ sys_hub_action_instance（1720）
処理の種類カタログ：wf_activity_definition（41）↔ sys_hub_action_type_base（1075）
実行履歴：wf_context（0）↔ sys_flow_context（8398）

今回確認した PDI（Zurich / OOTB）では、自動化が Flow Designer に一本化されていました。レガシー Workflow 側はテーブル構造と活動カタログだけが残って実体は空、という構成でした。件数の偏り（0 対数百〜数千）が世代交代をそのまま示しています。

ただしこれは新規 PDI（Zurich / OOTB）の話です。実環境では、過去に作られた wf_workflow が現役で動いていることも珍しくありません。自分の環境の移行状況は、wf_workflow の件数を見ると確実です。

公式コミュニティに、レガシー Workflow から Flow / Playbook への移行の考え方が説明されています。OOTB の自動1:1変換は無く、活動ごとに対応する Action へ作り直す方針です。

参考：Migrate Legacy Workflows to Flows and Playbooks

ServiceNow におけるレガシー Workflow のまとめ

ワークフロー定義は wf_workflow（Workflow）に入り、Flow と同じく sys_metadata 系メタデータです。今回の PDI では 0 件でした。
活動は wf_activity で、wf_workflow 直下ではなく wf_workflow_version（版）にぶら下がります（版管理が前提）。今回 0 件、固有フィールドは 26 でした。
実行履歴は wf_context（0件）に残り、状態は executing / finished / faulted / cancelled の4つです。設計（定義・活動）と実行ログは別テーブルです。
活動の種類カタログ wf_activity_definition は 41 件あり、Utilities 12 / Approvals 7 / Deprecated 6 が中心でした。Deprecated には Subflow / Run Workflow / SOAP / REST が含まれます。
レガシー Workflow と Flow Designer は、定義／ステップ／種類カタログ／実行履歴という同じ役割を別テーブルで担う二世代です。今回の PDI では Flow 側に一本化（Flow 定義 338 件）されていました。

レガシー Workflow を調べるときは、まず wf_workflow の件数でそもそも残っているかを確認します。残っていれば版（wf_workflow_version）→ 活動（wf_activity）→ 実行履歴（wf_context）の順に追います。

実機で気づいたこと

wf_activity_definition のカテゴリを見ていて意外だったのは、レガシー Workflow 自身の活動カタログの中に、すでに Deprecated（非推奨）という分類が用意されていたことです。Subflow・Run Workflow・SOAP Message・REST Message がここに入っており、Flow Designer に置き換わる前から、この仕組みの中で「もう使わない部品」がラベル付けされていました。外側からの世代交代というより、内側からゆっくり縮小していった痕跡に見えます。
wf_workflow が0件だからといって、レガシー Workflow の仕組みそのものが消えているわけではありませんでした。テーブル定義、活動の種類カタログ41件、実行状態の選択肢まで、Zurich の新規 PDI にもそのままそろっています。動かなくなったのではなく、初期データが同梱されなくなっただけだと考えたほうが実態に近いようです。過去に作ったワークフローがある環境なら、同じ仕組みでいまも動くはずです。
wf_workflow と wf_activity_definition だけが sys_metadata を継承し、Update Set の対象になります。一方 wf_workflow_version・wf_activity・wf_context は継承のないルート基底テーブルで、Update Set には乗りません。設計そのもの（定義とカタログ）は環境間で運べても、版・活動・実行履歴といった実データはインスタンスの中に閉じている、という線引きがテーブル構造に表れていました。

次に読むなら

この先に続くのは、次のテーマです。

レガシー Workflow の版管理（チェックアウト／公開）の挙動
Approval - User / Approval - Group アクティビティが裏で生成する承認レコード（sysapproval_approver）との関係
実環境での Workflow から Flow への移行手順

定義（wf_workflow）と版（wf_workflow_version）を分けて理解すると、編集が反映されない原因（公開していない版を見ている）が説明できます。これらは本記事のテーブルの関係・実行履歴の先にあたり、別記事で扱う予定です。

用語

PDI：Personal Developer Instance（無料の検証用インスタンス）
OOTB：Out of the Box（初期設定のまま）
Workflow（wf_workflow）：レガシーなワークフロー定義そのもの
Workflow Version（wf_workflow_version）：定義の版（活動はこれに属する）
Workflow Activity（wf_activity）：ワークフロー内の1つの活動
Activity Definition（wf_activity_definition）：活動の種類カタログ（Approval / Timer 等）
Workflow context（wf_context）：ワークフローが実行された履歴

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

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

テーブル定義          : sys_db_object_list.do?sysparm_query=name=wf_workflow^ORname=wf_activity^ORname=wf_context^ORname=wf_activity_definition
Workflow 一覧         : wf_workflow_list.do?sysparm_query=ORDERBYname
活動定義（カタログ）   : wf_activity_definition_list.do?sysparm_query=ORDERBYcategory^ORDERBYname
活動フィールド一覧     : sys_dictionary_list.do?sysparm_query=name=wf_activity^elementISNOTEMPTY
context 状態の選択肢   : sys_choice_list.do?sysparm_query=name=wf_context^element=state^inactive=false^ORDERBYsequence

テーブルの基本

wf_workflow … Label：Workflow ／ Extends：sys_metadata（Application File）／固有フィールド 10
wf_workflow_version … Label：Workflow Version ／ Extends：なし（ルート基底）
wf_activity … Label：Workflow Activity ／ Extends：なし（ルート基底）／固有フィールド 26
wf_activity_definition … Label：Workflow Activity Definition
Extends：wf_element_definition → sys_metadata ／固有フィールド 5
wf_context … Label：Workflow context ／ Extends：なし（ルート基底）／固有フィールド 39
レコード件数：wf_workflow 0（published 0）／ wf_workflow_version 0 / wf_activity 0 / wf_context 0
wf_activity_definition 41（active 41）／ wf_stage 3 ／比較：sys_hub_flow 338

wf_activity_definition のカテゴリ別内訳（全41件・実測）

Utilities 12 / Approvals 7 / Deprecated 6 / Conditions 4 / Tasks 4
Notifications 2 / Timers 2 / Service Catalog 1 / Subflows 1 / Change Policy 1 / （空 category）1

wf_context の state 選択肢（sequence順・実測）

executing（Executing）/ finished（Finished）/ faulted（Error）/ cancelled（Cancelled）

主なフィールド（検索用）

wf_workflow：name / description / table（対象テーブル名）/ access / template
sys_overrides（→ wf_workflow 自己参照）
wf_activity：activity_definition（→ wf_element_definition）/ workflow_version（→ wf_workflow_version）
stage（→ wf_stage）/ parent（→ wf_activity 自己参照）/ vars / x / y / width / height / timeout
wf_context：workflow（→ wf_workflow）/ workflow_version（→ wf_workflow_version）/ started_by（→ sys_user）
stage（→ wf_stage）/ parent（→ wf_context 自己参照）/ state / schedule（→ cmn_schedule）

レガシー Workflow と Flow Designer の対応（件数・実測）

定義：wf_workflow 0 ↔ sys_hub_flow 338
ステップ：wf_activity 0 ↔ sys_hub_action_instance 1720
種類カタログ：wf_activity_definition 41 ↔ sys_hub_action_type_base 1075
実行履歴：wf_context 0 ↔ sys_flow_context 8398

検証範囲とおことわり

確認した範囲：wf_workflow / wf_workflow_version / wf_activity / wf_activity_definition / wf_context の階層
wf_workflow→sys_metadata、activity_definition→wf_element_definition→sys_metadata
version/activity/context はルート基底
固有フィールド数（workflow 10 / activity 26 / context 39 / activity_definition 5）
レコード件数（workflow 0・version 0・activity 0・context 0）
activity_definition 41、wf_stage 3、比較 sys_hub_flow 338
wf_activity_definition のカテゴリ別内訳（全41件）、wf_context の state 選択肢、主要フィールドと参照先。すべて PDI（Zurich / 2026-06-21 確認）の OOTB で取得しています
確認していない範囲（断定しません）：実ワークフローの中身（活動の並び・条件式）、wf_context の実行時挙動と state の実分布（0件のため）
版管理（チェックアウト／公開）の動作、Workflow Editor のグラフィカル UI 操作
Workflow から Flow への実移行手順、本番環境で残存する wf_workflow の件数・構成。これらは別記事で扱います

今回は新規 PDI の OOTB（初期設定）を前提に、レガシー Workflow の構造を確認しました。Zurich の新規インスタンスでは OOTB レガシー Workflow が同梱されないため定義は0件でしたが、実環境では過去に作られた wf_workflow が現役で残っていることがあります。移行状況は wf_workflow の件数で確認してください。