Flow Designerのフローが動かないときどこを見る？ 実行記録sys_flow_contextで切り分ける

フローを有効化したはずなのに、何も起きない。エラーも出ない。このときフォームを眺めても原因は見つかりません。見るべきは実行記録（sys_flow_context）です。記録の状態が「0件」「Waiting」「Complete」のどれかで、原因の場所が決まります。この3分岐を背骨に、Australia PDIの実測で切り分け方をまとめました。

この3つで直れば、以降を読む必要はありません。①で記録があれば、状態を見てWaitingかCompleteの節へ進みます。記録が無ければ②と③です。それでも解けないときだけ、原因別の節を順に確かめてください。

切り分けの背骨は「実行記録の3分岐」

最初に押さえる事実が1つあります。フローが起動しなかったとき、その痕跡はどこにも残りません。対象レコードにも一覧にも、警告は出ないのです。だから調査は「動かなかった証拠」ではなく「動いた記録」を探します。

分岐は3つです。記録が0件なら、フローは起動していません。原因はトリガー側にあります。Waitingなら、フローは動いています。人の作業（承認かタスク）を待っているだけです。Completeなら最後まで動いています。期待と違うのは中身の設定です。

以降の節は、すべてこの3分岐のどれかに紐づけて進めます。

前提：フローは非同期で動く。直後の0件は誤認のもと

Business Ruleはレコード更新と同じ処理の中で走ります。フローは別方式です。いったんキューに積まれ、別処理で実行されます。実測では、操作直後の実行記録は名前が空のQUEUED状態でした。名前と状態が入るまで数十秒かかっています。0件と判断するのは、1分待って再読み込みしてからです。

実行記録の見え方には権限の設定もあります。関連プロパティの公式説明はこうです。

既定値はtrueでした。自分には記録が見えるのに、他の担当者には見えない。そういう相談が来たら、このプロパティとフローへのアクセス権を確かめます。

Flow Designerの位置づけは、プラグイン（v_plugin）の公式説明にこうあります。

スクリプト系の自動化との使い分けは別記事に譲ります。この記事は「動かないときの見つけ方」だけを扱います。

0件の原因①：StatusがDraftのまま。ActiveがtrueでもDraftは動かない

記録が0件のとき、最初に見るのはフローのStatusです。StatusとActiveは別のフィールドです。Statusは公開済み（published）か下書き（draft）かを表します。Activeは有効か無効かです。動くのはpublishedかつtrueのフローだけです。

このPDIにはフローが394本入っています。内訳を並べます。

Workflow Studio（旧Flow Designer）の一覧では、StatusとActiveが別の列に並びます。この2列を必ず両方見ます。

「Activeはtrueなのに、StatusはDraftのまま」というフローも実在します。一覧をactive=true^status=draftで絞ると出てきます。

自作フローで多いのはこのパターンです。編集して保存しただけではDraftのままです。Workflow Studio右上のActivateを押して、初めてpublishedになります。編集後の再有効化も同じです。修正を保存したら、もう一度Activateを押します。押し忘れると、直前のpublished版が動き続けます。「直したのに挙動が変わらない」ときは、まずここを疑ってください。

警告：一覧やスクリプトから直接直さない。直したつもりで直らない

ここに実務上の罠があります。sys_hub_flowのレコードを一覧やスクリプトから直接更新しても、保存されません。実測では、Activeをfalseに書き換えてもエラーが出ませんでした。しかしレコードは変わっていません。更新日時も元のままでした。

つまり「直したつもりで直っていない」状態が、警告なしに起きます。フローの操作は必ずWorkflow Studioの画面で行います。ActivateもDeactivateも同じです。

0件の原因②：トリガーが無い、または条件に達していない

Statusに問題が無ければ、次はトリガーです。トリガー定義（sys_hub_trigger_instance）は一覧で直接開けます。「このテーブルを起点にするフローがあるか」をここで確かめます。

このPDIのトリガーは、レコード起点が95本で最多でした（作成43・作成または更新28・更新24）。ほかにSLAタスク6本・サービスカタログ5本などが続きます。

incidentには注意が要ります。レコードトリガーは15本ありますが、全部がテンプレートフローです。中身はJIRA連携・Teams通知・Zoom会議・VIP割り当てなどでした。StatusはすべてDraftです。だからOOTBのPDIでは、インシデントを何件起票してもフローは1本も動きません。実行記録をsource_table=incidentで検索した結果は、全履歴で0件でした。これはOOTBの仕様です。

Draftと条件の壁は重なることもあります。例としてVTB Sample Flowを見ます。トリガー条件はpriority=1でした。そのうえStatusはDraftです。優先度1のインシデントを作っても動きません。条件を満たす前に、Statusで止まっているからです。試すならテンプレートをWorkflow Studioで開きます。中身を確認してからActivateする、の順です。

条件不一致を疑う場面では、公式のデバッグ用プロパティが使えます。

起動しなかった理由は、普段はどこにも残りません。このプロパティにテーブル名を入れたときだけ、理由がログに出ます。既定値は空です。条件の判定材料は「レコードが変更された瞬間の値」です。あとからレコードを直しても、過去の評価はやり直されません。

0件の原因③：そもそもフローが紐づいていない

カタログ申請では、この原因が独特の形で現れます。実例で確かめました。フロー未設定のアイテム「Office Keys」を1件注文します。リクエスト承認は通りました。しかしRITMの実行記録は0件のままです。履行タスクも作られません。stageはRequest Approvalから動きませんでした。

原因はアイテムのProcess Engineタブにあります。Flow・Workflow・Execution Planの3欄が、すべて空でした。

このPDIのアクティブな標準アイテムは71件です。うちフロー設定ありが43件、FlowもWorkflowも無しが23件でした。未設定組にはConference Room ReservationsやOffice Keysが並びます。こうしたアイテムは、注文しても誰もstageを進めません。放置されたRITMとして残り続けます。

直し方は明快です。アイテムのProcess Engineタブを開き、Flow欄にフローを設定するだけです。汎用の履行で良ければ、OOTBの「Service Catalog item request」がそのまま使えます。動くアイテムのFlow欄は、実際にこうなっています。

Waitingの実例：注文1件は2回の承認待ちを挟んで進む

Waiting分岐の実例を1本だけ見せます。フロー設定ありのStandard Laptopを注文しました。流れは次の1枚のとおりです。

注文直後、RITMの実行記録は0件でした。ここで焦らないでください。記録はリクエスト（sc_request）側にあります。「Service Catalog Request」フローがWaitingで承認を待っていました。

承認すると、今度はRITM側のフローが起動します。そして2段目の承認（Dept. Head Approval）で再びWaitingになりました。

2段目も承認すると、履行タスクSCTASK0010001が作られました。フローはタスク完了待ちのWaitingで残ります。つまりWaitingの待ち先は2種類です。承認（sysapproval_approver）か、タスク（sc_task）のどちらかになります。

見分け方は単純です。sysapproval_approverをrequestedで検索します。残っていれば承認待ちです。無ければsc_taskを見ます。未完了のタスクがあれば、それが待ち先です。どちらも担当者へ声をかければ前に進みます。フローを疑う前に、まず人の作業の滞留を疑う。Waiting分岐の要点はこの一言に尽きます。承認の追い方は承認の完全ガイドに、2段構えの仕組みは承認は2段構えの記事に譲ります。

実行記録のフォームを開くと、起点レコードと状態が1画面で読めます。

今回の実測では、注文からタスク生成まで数分でした。間に承認を2回挟んでいます。承認が人待ちになる本番なら、ここは数時間から数日に伸びるはずです。Waitingの長さは、そのまま承認の滞留時間を映します。

RITMフォーム上部のstageも手掛かりになります。今回はDept. Head Approval、そしてOrder Fulfillmentと進みました。stageの名前が承認系なら、待ち先はまず承認です。

2つのアイテムの結果を並べます。同じ注文操作でも、分岐が違えば止まり方が違います。

Completeなのに期待と違うなら、見るのは中身とログ

Completeは「フローは最後まで動いた」という意味です。結果が期待と違うなら、原因はアクションの中身にあります。実行記録のフォームを開き、各アクションの結果を上から順に追うのが基本です。分岐（If）のどちらへ進んだかも、ここで確かめられます。

ログはsys_flow_logに残ります。ただしログレベルの既定はWARNです。正常時の詳細は残りません。詳しく見たいときだけレベルを変え、終わったら戻します。ログの読み方はsyslogの記事が使えます。

「トリガー条件は合っているのにIfで落ちていた」という誤認が、この分岐では定番です。トリガー条件とフロー内のIfは役割が違います。トリガーは起動の門番です。Ifは起動後の分かれ道にあたります。実行記録があるなら、疑うのはIf以降になります。

確認順の一覧表

3分岐と確認箇所を1枚にまとめます。上の3行が「0件」用です。実行記録・StatusとActive・トリガー条件の順に見ます。4行目の承認はWaiting用です。5行目のProcess Engineはカタログ固有の0件原因になります。最終行のログはComplete用です。印刷して手元に置ける粒度にしてあります。

Run Asは最後に疑う

フローには実行ユーザーの設定（Run As）があります。このPDIでは「起動したユーザー」が278本、「システムユーザー」が113本でした。ユーザー実行のフローは、起動した人のACLで動きます。権限が足りないと、フローは起動したのに中の操作だけが失敗する形です。実行記録は残るため、0件とは症状が違います。

今回の実験は管理者で行いました。権限差による失敗は再現していません。エラー系の記録が残り、起動者の権限が弱いと分かっているときに疑う場所です。設定値の確認先はフローのトリガー画面です。一覧で見るなら、sys_hub_flowのrun_as列を足します。逆にシステムユーザー実行のフローは、誰の操作でも同じ強い権限で動きます。権限エラーには強い設定です。そのぶん、見せてはいけないデータまで処理できてしまいます。新規に作るときは、この違いを踏まえてどちらかを選びます。

実機を見て気づいたこと

1回の注文で、実行記録は複数の行に分かれました。リクエスト側のフローとサブフロー、RITM側のフローが別の行です。どの行が目当てのフローかは、source_recordの列で見分けます。一覧にこの列を足しておくと調査が速くなります。

source_recordフィールドの公式説明（hint）は「The source script of this execution」でした。実際に入るのはスクリプトではなく起点レコードへの参照です。説明文の方が実態とずれている例として覚えておきます。

フロー394本に対し、直近の実行記録は通知系のスケジュール実行ばかりでした。日常的に動いているフローは少数です。実行記録の一覧は、その環境で本当に使われている自動化の棚卸しにも使えます。

操作直後のQUEUED状態（名前が空の行）も、知らないと壊れた実行に見えます。実際は数十秒で名前と状態が入りました。前提節に書いたとおり、判断は1分待ってからです。

用語

• sys_hub_flow … フローの定義。Status（published/draft）とActiveを持つ

• sys_flow_context … フロー1実行＝1レコードの実行記録。画面名はFlow engine contexts

• Workflow Studio … フローを編集・有効化する画面。旧名はFlow Designer

• Process Engine … カタログアイテムにフロー/ワークフローを紐づけるタブ。エンジンは1つだけ選ぶ

• sysapproval_approver … 承認者1人につき1件作られる承認レコード。Waitingの正体を確かめる場所

• Run As … フローを起動者の権限で動かすか、システムユーザーの権限で動かすかの設定

• sys_flow_log … フロー実行のログテーブル。既定のログレベルはWARN

• Activate … フローをpublishedかつ有効にするWorkflow Studioのボタン。保存とは別の操作

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

• /sys_flow_context_list.do?sysparm_query=source_record=<レコードのsys_id> … 対象レコードを起点にした実行記録

• /sys_flow_context_list.do?sysparm_query=state=WAITING … 待ち状態の実行をまとめて洗い出す

• /sys_hub_flow_list.do?sysparm_query=active=true^status=draft … Activeなのに下書きのままのフロー

• /sys_hub_trigger_instance_list.do … トリガー定義の一覧（種類とフローの対応）

• /sysapproval_approver_list.do?sysparm_query=state=requested … 滞留中の承認

• /sc_cat_item_list.do?sysparm_query=active=true^flow_designer_flowISEMPTY^workflowISEMPTY … エンジン未設定のカタログアイテム

• /sys_flow_log_list.do … フロー実行のログ（既定はWARN以上のみ）

引用した公式説明を自分で開く

この記事で引用した説明文は、ServiceNowが製品に同梱しているドキュメントです。

• Flow Designerプラグイン群の公式説明（引用元）：/v_plugin_list.do?sysparm_query=idSTARTSWITHcom.glide.hub^descriptionISNOTEMPTY

• トリガー条件デバッグ用プロパティの公式説明（引用元）：/sys_properties_list.do?sysparm_query=nameLIKEflow_trigger

参考リンク

• KB0722358: Flow Designer is not executing as expected — フローが動かないときの公式ナレッジ（本筋）

• KB2977010: Diagnosing and Resolving Common Flow Designer Issues for Top Misconfiguration Patterns — 設定ミスの定番パターン集（本筋）

• KB0855865: How to rerun flow designer? — 原因を直した後の再実行手順

• KB0813130: Fix Flow Designer expression errors by recompiling — 式エラーを再コンパイルで直す手順

検証範囲とおことわり

数値と挙動はAustralia PDI（OOTB）で2026-08-29に確認したものです。フロー394本などの件数はこのバージョンの値で、環境により変わります。検証で作成したのはリクエスト2件（REQ0010001・REQ0010002）とその配下のRITM・タスク・承認、およびNew状態の変更要求1件です。いずれもデータレコードで、設定は変更していません。sys_hub_flowへの直接更新は保存されなかったため、OOTB設定は元のままです。

condition_debugプロパティは説明文の引用にとどめました。値の変更と動作確認は検証範囲外です。Run Asの権限差が実際にどう失敗するかも、権限の弱いユーザーでの再現が必要なため別の検証に譲ります。トリガー種類の集計は、REST APIで取得できた120件のトリガー定義に基づきます。

関連記事

• Flow Designerの中身は3テーブル（sys_hub_flow） — フロー定義がどのテーブルに保存されるかを先に押さえたい人向け

• ServiceNowの自動処理はどこに書く？ Business Rule / Client Script / Script Include / Flow の役割と判断基準 — フローとスクリプト系自動化の使い分けを決める判断編

• 承認は2段構え：1段目だけでは履行が始まらない（RITM/Catalog Task） — 今回のWaitingの正体だった2段階承認を詳しく追う実務編