[Brazil調査] Workflow Studioのデバッグ入力変更とエラー時イベント：アップグレード直後のPDIでは出なかった

夜中に止まったフローを、朝になって利用者の問い合わせで知る。そうならないよう、失敗した時点で自動で気づきたい場面があります。Brazil の公式リリースノートには、2つの機能が載っています。フローがエラー、キャンセル、割込推定の状態に入ったときのシステムイベント発行と、デバッグ中の入力値の差し替えです。

Australia から Brazil へメジャーアップグレードした PDI で確かめると、どちらの機能も画面に出ませんでした。同じ画面に Workflow Studio ストアアプリの更新バナーが出ていたため、ストアアプリの版数が関係していると私は見ています。ただし更新していないので、原因かどうかは未確認です。この記事では公式の説明、実機で見えたもの、更新前にできる代替策を順に書きます。

検証環境：Brazil PDI（Australia からメジャーアップグレード）/ OOTB / 2026-10-09 確認

①のバナーに「New version available: Upgrade to get the latest Workflow Studio features.」と出ています。インスタンス本体を Brazil にしたあとも、Workflow Studio はストアアプリとして更新待ちの表示でした。更新すると機能が使えるようになるかは、今回は確かめていません。

公式ドキュメントの説明

リリースノート「Brazil Early Availability」には、フロー関連の新機能として次の4つが並びます。

• 強化版 Workflow Studio フローデザイナー

• フロートラブルシューティングエージェント（AI）

• デバッグ中の入力変更

• エラー、キャンセル、割込推定の状態に入ったときのシステムイベント発行

（訳：フローがエラー、キャンセル、割込推定の状態に入ったときにシステムイベントを発行する。既定のイベント名を使うか、任意のイベント名を指定できる）

引用元：Brazil Early Availability

イベントの項目はリンクが空で、専用ページがありません。イベント名の既定値とパラメータは、公開されている Brazil のドキュメントから確認できませんでした。この記事でも名前は断定しません。

デバッグ入力の変更は、Flow debugger のページに書かれています。ブレークポイントで止めたステップの設定値を、フローを編集せずに一時的に書き換える機能です。

（訳：一時停止したステップの設定値を上書きして、新しい値でフローがどう動くかを確かめる）

引用元：Flow debugger

画面の部品として「Modify Inputs ボタン」が追加されており、書き換えたあとは実行詳細に元の設定値と書き換えた実行時の値が並びます。割込推定（Presumed Interrupted）は、15分を超えて実行中で現在のノードに有効なトランザクションがない場合などの状態です。

Australia のデバッガー

Australia 版の Flow debugger のページには、ブレークポイント、再開、ステップ実行が書かれています。入力を書き換える操作はありません。デバッガー本体は Australia から使えるもので、Brazil で足されたのは入力の変更です。

イベントについても、Australia の変更管理や Flow Designer のドキュメントに該当する記述はありません。失敗の検知は、フローの Error Handler か、実行記録（sys_flow_context）を調べる方法でした。実行記録の見方はフローが動かないときの切り分けで扱っています。

デバッグ画面の入力変更ボタン

Log を2つ並べたサブフローを作り、Test から Debug を選びました。別タブでデバッグ画面が開き、ブレークポイントと5つのデバッグ操作が使えます。

• ①は再開、ステップオーバー、ステップイン、ステップアウト、ブレークポイントのスキップ

• ②は Log の Message が「original log message」と表示されるだけの表

• ステップ2で止めた状態も確認したが、Modify Inputs のボタンは出なかった

公式のページにある「6. Modify inputs button」に当たる部品が見当たらないため、デバッグ中の入力変更は使えない状態です。

失敗時の実行記録

イベントを確かめるため、わざと失敗するフローを作りました。サブフローの3つ目に、Script ステップで例外を投げるカスタムアクションを置いて Test で実行しています。

実行記録の state は ERROR になりました。ヘッダーに Go to error が出て、3つ目のアクションに投げた例外のメッセージが表示されます。1つ目と2つ目の Log は Completed のままです。

前後のイベントログ

実行記録が ERROR になった時刻の前後 90 秒について、イベントログ（sysevent）を text_index を除いて確かめました。

並んだのは次のイベントです。

• login と session.established

• glide.heartbeat

• live_feed.update

• pa.dc.collect.predictive.completed

• flow.fire

flow.fire はキューが flow_engine、対象テーブルが sys_flow_context の内部イベントです。内部キュー用のイベントで、今回探している失敗通知用のイベントとは区別しました。

イベントログ全体でも、名前に flow を含むのは flow.fire だけでした。

イベント登録の検索結果

イベント登録（sysevent_register）を flow や interrupt で検索すると13件が該当します。assessment、quiz、workflow.notification などで、フロー実行の失敗とは関係がありません。

システムプロパティ（sn_flow_designer 系と com.snc.process_flow 系）にも、イベント発行を切り替える項目は見つかりませんでした。キャンセル状態の実行記録は既存で52件ありますが、対応するイベントも特定できませんでした。

今回の確認条件では対象のイベントを特定できず、Script Action でイベントを受ける検証には進めませんでした。

Error・Cancelled・Presumed Interrupted の違い

イベントの発行対象になる3つの状態は、止まり方が異なります。公式の Flow execution details のページでは、次のように説明されています。

• Error は、アクションなどが失敗してフローがそこで止まった状態です。ヘッダーに Go to error が出ます

• Cancelled は、フローの実行時間がタイムアウト値を超えたか、人が手動で止めた状態です

• Presumed Interrupted は、15分を超えて実行中で現在のノードに有効なトランザクション ID がない状態です。別のノードで8時間を超えた場合も同じ状態になり、トランザクションの終了やノードの再起動が原因と考えられます

引用元：Flow execution details

通知には状態名を含め、Error、Cancelled、Presumed Interrupted を区別します。次のように対応が分かれるためです。

• Error は設計か入力の見直しから始める

• Cancelled はタイムアウト値と手動操作の記録を確認する

• Presumed Interrupted はノードの再起動やトランザクションの打ち切りを疑う

イベントが使えるようになったら、状態ごとに受け先を分けて検討するのが現実的です。

Error Handler の状態表示

すでに使える失敗の扱いとして、Error Handler があります。有効にすると、フロー実行の詳細に Completed (error caught) などの状態が出ます。

（訳：フローがエラーを捕捉し、Event Handler セクションの項目を実行し終えたときに生成される状態）

引用元：Flow error handler

実行記録（sys_flow_context）の側では、正常に捕捉・処理されたエラーは Complete と表示されます。そのため、ERROR だけで絞る監視では拾えません。Error Handler の内部で別のエラーが起きた場合は Error になります。捕捉したエラーも見逃さないよう、Error Handler の中で通知や記録を行う設計にしておくと安心です。

アクションのエラー評価

今回のテストでは、Script ステップの例外がアクションの Action Status に入り、コード1とエラーメッセージになりました。アクションにはエラー評価の機能があり、ステップの失敗で止めるか、次のステップへ進めるかを選べます。

引用元：Action error evaluation

失敗を再現する手順は、公式にも「Create a custom action to throw an error」として載っています。入力値が1のときだけ例外を投げるアクションを作る手順です。今回は入力を持たない簡略版にしました。

引用元：Create a custom action to throw an error

フロートラブルシューティングエージェント

Brazil のリリースノートには、会話からフローのエラーを診断するフロートラブルシューティングエージェントも載っています。実行データを解析し、ビジネスルールとの競合を見つけて対処を提案する機能です。

引用元：Flow troubleshooting agent

AI 機能で、有効化の手順やライセンスの確認が別に必要なため、この検証では動かしていません。

Test と Debug の呼び出し元

Test ボタンの実行と Debug の実行は、どちらも実行記録に残ります。実行記録には呼び出し元の項目（calling_source）があり、Test と Debug で値が分かれる想定です。値の一覧は今回記録しておらず、自分の環境で確かめてください。

この違いは、失敗の監視でノイズを除く手がかりです。開発者が手元で試した失敗を運用の通知に混ぜないため、監視の条件に呼び出し元を加えましょう。

入力変更の試し方

公式の例では、Log アクションの Message と Look Up Records の件数上限を書き換えています。書き換えたあと、実行詳細には実行時の値と設定値が別々に出ます。

• 実行時の値は、デバッグ中に書き換えた「Modified log message」

• 設定値は、フローに保存されている「Original log message」のまま

つまり、フローを保存し直さずに、特定の入力値でエラーになるかどうかを切り分けられます。更新後は、今回作ったような Log を並べたサブフローで、Message を書き換えて両方の値が並ぶかを最初に見ます。

イベントを受けるときの構成の候補

イベントが発行されるようになれば、受け側は2通り考えられます。どちらも今回は検証できていないため、更新後の確認項目として挙げます。

• Script Action でイベント名を指定し、gs.info で記録する。パラメータの中身を知る最初の手段になる

• イベント起動のフローを作り、チケットの起票や通知につなげる

まず Script Action でログだけを出し、パラメータにフロー名や実行記録の ID が入っているかを見ます。入っていれば、通知側で実行記録へのリンクを組み立てられます。

更新前の実務

更新前に確認する項目

イベント方式は、Workflow Studio のストアアプリを更新してから確かめる前提です。更新で使えるようになるかは未確認です。更新は本番に影響するので、検証用インスタンスで先に行い、次の順で確認してください。システムプロパティの一覧は Workflow Studio flow system properties にあります。

• デバッグ用の実行詳細の出方は Flow execution settings のレポートレベルに左右される。公式では、レポートレベルは実行記録（context）とログのレコードには影響しないとされているため、sys_flow_context の監視とは分けて確認する

• sys_store_app で Workflow Studio と Flow Designer のバージョンを控える

• 更新後に sysevent_register を flow で検索し、新しいイベント名があるかを見る

• 失敗するテストフローを実行し、sysevent に出る名前とパラメータを控える

• そのイベント名で Script Action かイベント起動のフローを作る

更新前の代替は、実行記録の state が ERROR のものを定期的に拾う方法です。スケジュールジョブで sys_flow_context を ERROR で絞り、件数が0でなければ通知します。即時性は落ちますが、Australia のままでも使える方法です。サブフローの失敗を親へ伝えたくない場合は、Error Handler を有効にしてください。

実機で気づいたこと

メジャーアップグレードのあとでも、Workflow Studio は 30.0.4、Flow Designer は 30.0.7 でした。ストアアプリの版数は、本体のリリースとは別に管理されます。リリースノートの機能が画面に出ないときは、この版数を控えておくと、更新前後で比べられます。

もう1つ、検証中に引っかかった点があります。カスタムアクションの Script を直して再公開しても、すでにサブフローに置いてあるステップは古いバージョンのまま動きました。ステップを削除して置き直すと、新しいバージョンで動いて ERROR になりました。アクションを直したのに挙動が変わらないときは、フロー側のステップを置き直します。

アクション入力にスクリプトを書いて例外を投げる方法では、フローは失敗しませんでした。値が空になって Completed で終わります。失敗の再現には、Script ステップを持つアクションを使います。

旧 Flow Designer のリダイレクト

プロパティ sn_flow_designer.disable_flow_designer_workflow_studio_redirection は false で、旧 Flow Designer の URL を開くと Workflow Studio へ移ります。説明は「Disable redirection from flow designer to workflow studio」です。

（訳：Flow Designer から Workflow Studio へのリダイレクトを無効にする）

引用元：/sys_properties_list.do?sysparm_query=nameLIKEsn_flow_designer.disable

今回の画面はすべて Workflow Studio です。

失敗フローを自分で再現する手順

同じ検証をするときの流れです。名前の先頭を「記事検証:」にしておくと、後片付けで検索しやすくなります。

1. Workflow Studio の New からアクションを作り、Script ステップに throw new Error('test'); を書く

2. Save のあとに値が保存されたかを確かめ、Publish する。今回は最初の保存が反映されず、Script がテンプレートのままで公開された

3. New からサブフローを作り、Log を2つ置いてから、作ったアクションを3つ目に置く

4. Test を実行し、実行詳細で3つ目が Error になるかを見る

5. 同じ時刻の前後で sysevent を開き、イベント名を確かめる

6. 終わったら、実行記録、サブフロー、アクションの順に削除する

手順2の保存漏れは、sys_variable_value の値を REST で引いて見つけました。画面で保存済みに見えても、保存されていない場合があります。

検証範囲とおことわり

• 検証日は 2026-10-09 です。PDI は Australia からメジャーアップグレードした Brazil Patch 0 で、Workflow Studio ストアアプリは更新していません

• ストアアプリの更新はアンインストールできない変更になり得るため実行していません。更新後にイベントと入力変更が出るかは未確認です

• イベント名の既定値とパラメータは、公開ドキュメントに記載がなく確認できていません

• テストで作ったサブフロー、アクション、実行記録、ログは削除し、検索で0件を確認しています。設定値は変更していません

• 通信やメール送信は行っていません

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

この記事の画面は、次のパスを自分のインスタンスで開くと同じ一覧を確認できます。

• ストアアプリの版数：/sys_store_app_list.do?sysparm_query=scopeINsn_workflow_studio,sn_flow_designer,sn_flow_diagram

• フローの実行記録：/sys_flow_context_list.do?sysparm_query=state=ERROR^ORDERBYDESCsys_created_on

• イベントログ：/sysevent_list.do?sysparm_query=nameLIKEflow^ORDERBYDESCsys_created_on

• イベント登録：/sysevent_register_list.do?sysparm_query=event_nameLIKEflow

• 実行設定の項目：/sys_flow_execution_setting_list.do

アップグレード直後にまず見るのは、1つ目の版数です。続いて、2つ目の ERROR の一覧と、4つ目のイベント登録の名前を、更新の前後で並べて比べます。

付録：用語

• Workflow Studio：フロー、サブフロー、アクションを作る画面と、そのストアアプリ

• Presumed Interrupted：実行中のまま現在のノードで処理が確認できなくなった状態

• Error Handler：フローの中で失敗を捕捉して処理するための領域

• sysevent：システムイベントのログ。Script Action やイベント起動のフローが受け取る

• sys_flow_context：フロー1回分の実行記録

• ストアアプリ：インスタンス本体とは別に版数が管理されるアプリ

関連記事

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

• Flow が止まった場所を実行ログで探す

• Flow Designer の中身は3テーブル