Power AutomateでInvalidTemplateや式の評価エラーが出たら、error名だけで原因を決めず、保存時に止まったのか、run中の実データで失敗したのかを分けます。同じ式でも、編集時に分かる構文の誤りと、実行しないと分からないnull・型・配列の違いでは、確認する証拠が変わります。
この記事はcloud flowの式と参照の診断です。AzureのARM templateやdesktop flowの別機能へそのまま適用しません。Power Automateの編集・保存・実行や、外部データの更新は実施していません。入力例は架空で、製品での再現・修復成功を測定したものではありません。
目次
error全文と、止まった時点を固定する
保存・validation時のbannerなら、該当actionと式、直前のrenameや削除を確認します。runが作られているなら、最初に失敗したactionのInputs/Outputsと、その式が参照する直前の出力を見ます。外側のActionFailedだけでなく、内側のcode/messageと対象propertyを記録します。
表は横にスクロールできます
| 失敗する時点 | 最初に見る証拠 | まだ断定しないこと |
|---|---|---|
| 保存・validation | designerのerrorと式 | 接続先の一時障害 |
| 特定のrun・一部データ | 当該actionの実入力と参照元出力 | 全件で構文が壊れている |
| 前段失敗後の後続 | 前段状態とrun after | 後続式だけが根本原因 |
| import後 | 移行先の定義・参照・環境 | 元環境と同じ名前なら同じ値 |
Microsoftのerror reference（新しいタブで開く）は、InvalidTemplateをdesign-time、ExpressionEvaluationFailedをruntimeの分類で説明しています。一方、nullの公式troubleshooting（新しいタブで開く）にはruntimeのInvalidTemplate例もあります。codeの一語だけで段階を決めず、今回の実際の発生箇所を優先します。
保存できない場合は、最小の式から確認する
括弧・引用符・関数の引数数、参照先actionの存在を確認します。資料から貼った全角記号や不可視文字がないかを見て、疑わしい箇所だけ現在の式editorへ入力し直します。式を置く欄がexpressionなのか、文字列に埋め込む欄なのかも区別し、他の欄の構文を機械的に足しません。
actionをrename・移動・削除した直後なら、dynamic contentと内部参照を確認します。画面上の表示名から内部名を推測するより、現在の定義とeditorで選べる参照へ戻ります。並列branchやloopの外から、まだ存在しない出力を参照していないかも見ます。
保存が通るようになっても、実データで正しく計算した証拠にはなりません。構文・定義の検査と、データを使う受入確認を別に残します。
実行時は、期待した形と実際の形を並べる
参照した値がstring、number、object、array、nullのどれかを、失敗したrunで確認します。別の正常runだけを見て、いつも同じ形だと判断しないようにします。connectorやschemaの変更、空の検索結果、条件でskipされた前段も調べます。
表は横にスクロールできます
| 期待 | 架空の実入力 | 確認する方向 |
|---|---|---|
| 数字の文字列 | "未定" | 変換前の業務条件と型 |
| objectのproperty | null | 前段が値を返した条件 |
| 一件のobject | [] | 検索0件と配列の扱い |
| 日時 | 曖昧な日付文字列 | 元形式・locale・timezone |
| 分母 | 0 | 計算できない場合の分岐 |
この表は確認順の例で、すべてをdefaultの0や空文字へ変えればよいという意味ではありません。たとえば請求額が不明な値を0へ変えると、式は通っても業務結果が変わります。保留・通知・対象除外など、必要な扱いを先に決めます。
nullと空文字、0件と失敗を区別する
propertyへの安全なアクセスやnull処理を追加しても、その先の関数がnullを受け入れるとは限りません。式関数の公式reference（新しいタブで開く）で引数型を確認し、値がない場合はその変換へ進まない条件を設けます。
coalesceはnullに対するfallbackとして使えますが、空文字・空配列をすべて同じ値へ置換する機能だと考えません。空の値が正当なのか、未入力なのか、前段失敗の結果なのかを区別します。fallbackを採用するなら、その値の根拠と、元の欠損を後で追える記録を残します。
同様に、配列から最初の一件を取るだけで、複数候補の曖昧さが解消するわけではありません。0件、1件、複数件で何をするかを決め、対象の誤選択を式の成功で隠さないようにします。
短いComposeなどで、境界を一つずつ検査する
検証用の複製では、前段の生の形、property参照、型検査、変換、最終計算を分けて確認します。一つの長い式をまとめて替えるより、最初に期待と違う値になる境界を探します。顧客データを診断logへ複製せず、同じ型や欠損条件を持つ架空入力を使います。
表は横にスクロールできます
| 検査する条件 | 合格とする状態 | 不合格なら |
|---|---|---|
| 正常な実値 | 期待する計算結果と一致 | 参照・型・単位を再確認 |
| null・未入力 | 意図した保留等へ分岐 | defaultで隠さない |
| 空配列・複数候補 | 定義した件数条件で処理 | 一件と決めつけない |
| 前段の失敗・skip | 必要な失敗経路になる | 後続を成功と偽らない |
式が評価できること、正しいrecordを選ぶこと、外部更新が完了することは別の確認です。保存や一つのComposeが通っただけで、flow全体の成功にしません。
再実行前に、済んだ外部処理を確認する
通知の式が最後に失敗したrunでも、その前のrecord作成は済んでいる可能性があります。最初から再実行する前に、処理IDと外部状態を照合し、二重登録・二重送信にならない範囲を選びます。式の修正と、部分成功したrunの復旧を同じ操作にまとめないようにします。
変更前の式と参照、原因となった実入力の形、採用した分岐、検証した条件を記録します。意味が変わった場合は式の差分を戻し、未確認のデータを保留へ戻せるようにします。完了とはerror表示が消えたことだけでなく、欠損や例外でも意図した業務判断を保てることです。