SalesforceのFlow Loggingを実機検証-フローの成功・失敗を標準レポートで可視化-

投稿日： 2026.08.24
更新日： 2026.08.24

#レポート #Salesforce #失敗 #Flow Logging #実機検証

SalesforceのSpring ’26で強化されたフローロギング（Flow Logging）。デバッグログでは難しかったフローの成功・失敗の継続監視をData 360（旧Data Cloud）と標準レポートで実現する方法や、設定時の注意点、ID連携の罠まで解説します。

 
Salesforceのフロー障害を追うとき、デバッグログは詳細ですが、保存期間や再現性の面で継続監視には向きません。フローロギング（Flow Logging）は、対応するフローの実行メトリクスをData 360（旧Data Cloud）へ送り、Salesforce標準レポートからも参照できるようにする機能です。Spring ’26ではAutomation LightningアプリのFlow Logsタブから設定・監視をまとめて行いやすくなりました。

今回は、実際にロギングを有効化した組織で、Data 360側に作成されたデータストリーム、利用できるレポートタイプ、レポート上の関連付けを確認しました。単なる機能紹介ではなく、画面から読み取れるデータ構造と、運用設計で注意したい点まで整理します。

 

まず押さえたい：何をどこまで記録できるか

現在のSalesforce Helpでは、永続ロギングの対象としてレコードトリガーフロー、プラットフォームイベントトリガーフロー、スケジュールトリガーフロー、自動起動フローが案内されています。画面フローはこの対象一覧に含まれていません。利用前に、監視したいフロー種別がサポート対象かを確認してください。
設定はAutomation Lightningアプリ（自動化アプリ）の「フローログ」タブから進められ、フロー単位のプロパティでもロギング対象を管理できます。Data 360を利用するため、権限・データスペース・クレジット消費もセットで考える必要があります。

1. 実行単位の監視：FlowRunで成功／失敗、完了日時、対象レコードなどを確認
2. 要素単位の監視：FlowElementRunで、実行されたエレメントとその状態を確認
3. 継続的な可視化：標準レポートとダッシュボードで件数・傾向を集計
4. 詳細デバッグとの使い分け：変数値や決定要素の評価過程を追う用途はFlow Builderのデバッグやデバッグログを併用

従来の確認手段との違い

確認方法	フロー成功時	フロー失敗時	蓄積した実行ログの集計
フローエラーメール	×	○	×
デバッグログ	△	○	△
フローロギング＋レポート（本記事）	○	○	○

○：標準的に確認しやすい　△：取得設定・保存期間などの条件あり　×：その方法だけでは確認しにくい

有効化は「組織」と「各フロー」の2段階

フローロギングは、対象フローの設定だけでは開始できません。先に組織側でフローロギングのセットアップを行い、その後、ログを取得したいフローごとにロギングを有効化します。設定の順番は次のとおりです。

・組織側で有効化：Automation Lightningアプリのフローログタブ、またはフローの詳細プロパティからロギングのセットアップを開始

組織側のセットアップでは、フロー実行ログをData 360へ取り込むための構成が準備されます。検証環境では、この操作後にFlowRun／FlowElementRunなどのDMOと、それらへデータを届けるデータストリームを確認できました。作成される名称や件数、セットアップ完了までの時間は、組織やリリースによって異なる可能性があります。

・Data 360側を確認：セットアップによって用意されたデータストリームとDMOが利用可能な状態になっているかを確認

・対象フローで有効化：各フローのプロパティで、[このフローの永続的なロギングを有効化]をオンにして保存・有効化

対象フローでは、プロパティのロギング設定をオンにして保存します。設定後にフローを実行し、データストリームの取り込み件数とFlowRunのレコードを確認できれば、ログ収集までの導線を検証できます。
新しいフローや新しいフローバージョンを作成した場合は、バージョンごとに永続ロギングの設定を確認してください。

 

検証環境では7つのデータストリームを確認

初回設定後、Data 360のデータストリーム一覧を「flow」で絞り込むと、検証環境では7件が表示されました。内訳はデータコネクタが「取り込みAPI」の3件と、「Salesforce CRM」の4件です。

系統	データストリーム	主な役割
取り込みAPI	Flow Runs-FlowRun	1回のフロー実行
取り込みAPI	Flow Runs-FlowElementRun	実行内の各エレメント
取り込みAPI	Flow Runs-IdentityMatch	本検証では用途未確定
Salesforce CRM	FlowRecord_Home	フロー定義
Salesforce CRM	FlowRecordElement_Home	エレメント定義
Salesforce CRM	FlowRecordVersion_Home	フローのバージョン
Salesforce CRM	FlowRecordVersionOccurrence_Home	定期実行のオカレンス

 

取り込みAPI側：実行ログの中心は2つ

公式のDMO定義では、Flow Run DMOはフロー実行1回の詳細を、Flow Element Run DMOはその中で実行された単一エレメントの状態を表します。両者はFlow Run IDで関連付けられるため、まずFlowRunで異常な実行を絞り込み、次にFlowElementRunで要素を掘る、という基本的な調査導線になります。
・FlowRunの保持項目：Flow Run Status、Completed DateTime、Error Reason／Description、Flow Version、Primary Record ID／Objectなど
・FlowElementRunの保持項目：Flow Element Run Status、Flow Element、Flow Run、Scheduled／Completed DateTime、Error Reason／Descriptionなど

Get Recordsが返した件数、Assignment後の変数値、Decisionの条件式がどの値で評価されたか、といったデバッガーレベルの情報まではDMOの公開フィールドから確認できません。フローロギングは運用監視、Flow Builderのデバッグとデバッグログは原因究明、と役割を分けると使いやすくなります。

Salesforce CRM側：フロー定義とバージョンの基礎データ

CRMコネクタ側の4ストリームは、FlowRecord、FlowRecordElement、FlowRecordVersion、FlowRecordVersionOccurrenceに対応します。FlowRecordとFlowRecordVersionはAPI v58.0以降、FlowRecordVersionOccurrenceはAPI v60.0以降で利用できる標準オブジェクトです。実行ログとは性格が異なり、フロー名、エレメント定義、バージョン、定期実行のオカレンスといった“定義側”の情報を持ちます。

 

IdentityMatchは0件となった

Flow Runs-IdentityMatchも同時に作成されましたが、今回の検証ではレコード数は0でした。IdentityMatchというDMO自体はData 360のID解決でも使われる名称ですが、このテンプレートストリームがフローロギングで担う具体的な役割を、確認できた一次情報だけから確定することはできませんでした。
本記事では日常のフロー監視目的としてFlowRunとFlowElementRunを中心に検証します。

Data 360のデータを標準レポートで見る

Salesforce側でFlowRunやFlowElementRunなどカスタムレポートタイプを使って標準レポートを作成できます。Data360側でData Explorerを毎回開かなくても、通常のSalesforceレポートと同じ操作感でフィルタ、グルーピング、集計、グラフ化、ダッシュボード配置が可能です。

検証環境では、単体のFlow Run／Flow Element Runに加え、「Flow Element Runが関連するFlow Run」「Flow Runが関連するFlow Version」などの関連レポートタイプも表示されました。

レポート画面で見る主な項目

項目	記事内での意味
Completed Date Time	実行の完了日時
Flow Run Status	フロー実行全体の結果
Flow Element	実行されたフロー要素
Error Reason	エラーの種別・コード
Error Description	エラーの詳細メッセージ

画面の英語項目を上の意味で読み替えると、後述する成功・失敗の明細を追いやすくなります。

最初に作ると役立つ3つのレポート

・成功・失敗実行一覧：Completed DateTime、Flow Run Status、Flow Element、Error Reason／Descriptionを同じ明細に表示
・要素別の失敗／遅延候補：FlowElementRunをエレメント単位で集計し、ステータスと日時を比較
・日次・週次の実行推移：完了日でグループ化し、総実行件数と異常件数をダッシュボード化

上記レポートキャプチャでは、同じ完了日の明細に、成功したフロー要素のcheck_phone／update_Contactsと、失敗したフロー要素のassign_faxが並んでいます。失敗行のFlow Run StatusはERROR、Error ReasonはFIELD_CUSTOM_VALIDATION_EXCEPTIONです。Error Descriptionには、フローによるレコード更新が入力規則に違反したことと、対象項目のメッセージが記録されました。

成功と失敗を同じレポートで追えるのが大きな変化

従来の運用では、フローの問題調査はエラーメールや、その時点で取得したデバッグログから始めることが多く、正常終了した実行を後から標準レポートで一覧化するのは容易ではありませんでした。フローロギングでは、失敗だけでなくFINISHEDの実行も永続データとして確認できるため、「いつ失敗したか」と同時に「いつ正常に実行されたか」という観点を持てます。
成功ログが残ると、日別・時間帯別の実行回数、通常時の実行頻度、特定エレメントまで到達した件数を基準値として持てます。その上でERRORを同じレポートに重ねれば、単発の障害調査だけでなく、成功率やエラー増加の傾向を継続監視できます。ただし、FINISHEDはビジネス上の期待結果まで保証する値ではありません。

フロー名との関連付けで確認したIDのずれ

実行ログを監視するなら、最終的には“どのフローの実行か”を表示したくなります。公式のFlow Run DMO定義には、Flow RunからFlow Versionへの多対1（N:1）の関連が記載されています。そのため、構造上は次の経路を期待できます。

ただし今回のレポートで値を見比べると、FlowRunのFlow Versionには301で始まるIDが表示され、CRM同期側のFlowRecordVersion_HomeのIdには10vで始まるIDが入っていました。プレフィックスが異なるため、少なくともこの2項目をそのまま同一キーとして突合することはできませんでした。

確認箇所	ΙⅮ例	読み取れること
FlowRun.Flow Version	301BK0000…	Flowメタデータ側で見かけるID体系
FlowRecordVersion_Home.Id	10vBK0000…	FlowRecordVersion側のID体系

 

 
運用ダッシュボードを作る際は、まず少数の既知フローでFlow Versionからフロー名まで正しくたどれるかを確認しましょう。解決しない状態で301と10vを手動JOINする設計に進むと、バージョン更新やマッピング変更で保守負荷が高くなります。

導入時に見落としやすい運用ポイント

Data 360クレジットを前提に対象を絞る

フローロギングはData Cloudクレジットを消費すると案内されています。高頻度のレコードトリガーフローでは、FlowRunだけでなく実行エレメント数に応じてFlowElementRunも増えます。最初から全フローを対象にせず、障害影響が大きいフロー、失敗率を測りたいフロー、性能劣化を追いたいフローから段階的に有効化するのが現実的です。

公開前・本番導入前のチェックリスト

1. 対象フローが、公式Helpに記載されたロギング対応種別か
2. FlowRun／FlowElementRunに、通常実行した検証データが到着し、完了日時・ステータス・エラー項目が期待どおりか
3. 関連レポートタイプでFlowRunとFlowElementRunが同じFlow Run IDにひも付くか
4. Flow Versionからフロー名まで関連項目をたどれるか
5. 時刻表示のタイムゾーンと、レポート利用者のロケールが運用想定と合うか
6. クレジット消費とデータ保持方針を確認し、対象フローを段階的に広げる計画があるか
7. Primary Record IDやError Descriptionを誰が閲覧できるか、レポート共有範囲を確認したか

まとめ

・フローロギングは、単発のデバッグではなく、フローの実行状況を継続的に観測するための仕組みです。検証環境では、取り込みAPI側3件とSalesforce CRM側4件、合計7件のデータストリームが作成され、FlowRunとFlowElementRunを標準レポートで確認できました。

・実務で価値を出しやすいのは、失敗実行の一覧、要素別の異常傾向、日次・週次の実行推移です。公式DMOの関係定義と実データの両方を確認しながら、小さく始めることが重要です。

・「どの実行が、いつ、どの要素で失敗したか」をチームで共有できるだけでも、障害対応は属人的なログ調査から一歩進みます。まずは重要な数本のフローでデータ到着・関連付け・クレジット消費までを一巡させてから、本番の監視対象を広げてみてください。

参考資料

1. Salesforce Help: Persistent Flow Logging
2. Salesforce Help: Install Flow Integration Package
3. Developers: Flow Run DMO
4. Developers: Flow Element Run DMO
5. Developers: Flow Version DMO
6. Object Reference: FlowRecordVersion
7. Object Reference: FlowRecordElement
8. Salesforce Admins: Find and Fix Flow Errors
9. Salesforce Admins: Summer ’25 Flow Features

＜Salesforce＞
弊社ではSalesforceをはじめとするさまざまな無料オンラインセミナーを実施しています！
＞＞セミナー一覧はこちら

また、弊社ではSalesforceの導入支援のサポートも行っています。ぜひお気軽にお問い合わせください。
＞＞Salesforceについての詳細はこちら
＞＞Salesforceの導入支援実績はこちらからご覧いただけます！

医療業界に特化した営業支援、顧客管理(SFA/CRM)のコンサルティングも提供しております。こちらもぜひお気軽にお問い合わせください。
＞＞顧客管理(SFA/CRM)のコンサルティングの詳細はこちら