フローが「オン」でも、Dataverse 側の webhook 購読が登録できていなければ、イベントは永久に届かない。実行履歴が空でエラーも出ない場合、ロジックより先に「購読レコードが実在するか」を確かめる。とくにサービスプリンシパル（機械 ID）接続では、業務権限と購読登録権限は独立した別レイヤーにあり、権限不足で静かに失敗する。
「オン」は「購読が開通した」を意味しない
Dataverse の「行が追加されたとき」などのイベントトリガーは、フローを有効化した時点で Dataverse 側に購読（webhook）を登録しにいく。内部的には ServiceEndpoint テーブル（エンドポイント本体・contract = 8 が webhook を示す）と SdkMessageProcessingStep テーブル（どのテーブル・イベント・ステージで発火するかの設定）の 2 テーブルにレコードが立つ。この登録が成功してはじめて、回線が開通した状態になる。
フローの「オン」表示は、購読の登録成否とは独立して維持される。権限不足で登録が失敗してもステータスは ON のまま残り、エラーメッセージはユーザーに提示されない。Microsoft 公式ドキュメントには次の一文がある。
“Missing permissions or an invalid connection can silently cause triggers to not fire.”
（権限不足または無効な接続により、トリガーは静かに発火しない）
結果として、フローは ON のまま実行履歴は空のまま残る。健康診断ツールが「◯日間、一度も実行されていません」と表示するだけで、ログもエラーも出ない。
「フローがオン」と「購読が開通した」は、独立した別の事実だ。
サービスプリンシパル接続で静かに失敗する理由
Dataverse コネクタはサービスプリンシパル接続を公式にサポートしている。ただし、この構成では権限の二層構造に注意が必要だ。
サービスプリンシパルを Dataverse 接続として使う場合、Entra ID にアプリ登録を作成し、Dataverse 環境に Application User（Dataverse 側の機械 ID）として追加したうえで、セキュリティロールを割り当てる。このロールに 2 つのレイヤーがある。
| レイヤー | 内容 | 典型的なロール |
|---|---|---|
| 業務データ層 | 対象テーブルへの読み書き（CRUD） | カスタムセキュリティロール |
| プラットフォーム層 | 購読登録（ServiceEndpoint / SdkMessageProcessingStep の作成） | System Customizer / System Administrator |
業務データ層の権限だけを付与した Application User は、テーブルへのアクセスはできる。しかし購読の登録は失敗する。この 2 レイヤーは独立しているため、業務ロジックが動作する別の接続で確認済みであっても、機械 ID での購読登録成功を意味しない。
Dynamics 365 の公式ドキュメント（on-premises）には「購読ステップの登録には System Customizer または System Administrator ロールが必要」とある。Power Platform クラウドでの最小権限粒度（カスタムロールで代替できる範囲）は公式一次ドキュメントに明示がなく、カスタムロールで最小化する場合は Dataverse プリビレッジ一覧との照合を推奨する。
購読不発を診断する三手
実行履歴やエラーログを追う前に、購読の実体と主体の権限を直接確認する。
手① 購読レコードが実在するかを確認する
購読が登録されているかどうかは、以下のいずれかで直接確認できる。
GUI 経路 A：Power Apps メーカーポータル
- make.powerapps.com にサインイン
- 左ナビ「ソリューション」→「Default Solution」を開く
- オブジェクト一覧から「プラグインステップ」を選択して一覧を確認
GUI 経路 B：Power Platform 管理センター
- admin.powerplatform.microsoft.com にサインイン
- 設定 → ユーザー + アクセス許可 → プラグイン
なお、Power Automate の Dataverse トリガーがプラグインステップビューに表示されるかどうかは、実機での確認を推奨する（間接的な情報は得られているが、公式一次記述での確認は未達）。
Web API 経路（開発者向け）
# webhook エンドポイントの確認（contract=8 が webhook を示す）
GET [org URI]/api/data/v9.0/serviceendpoints?$filter=contract eq 8
# ステップの確認
GET [org URI]/api/data/v9.0/sdkmessageprocessingsteps
StateCode=0 が有効（Enabled）、StateCode=1 が無効（Disabled）を示す。レコードが存在しない場合、購読の登録が失敗している。
手② 「◯日間未実行」警告を購読レコードと合わせて読む
健康診断ツールの「◯日間未実行」という警告は、購読済みでイベントが来ていない状態にも、購読そのものが未登録の状態にも同じ文言が出る場合がある（実務観察ベース・公式の明示記述は未確認）。この警告単体では原因を特定できないため、手①で購読レコードの実在を確認してから解釈する。
| 購読レコードの状態 | 「◯日間未実行」の解釈 | 次のアクション |
|---|---|---|
| あり（StateCode=0） | 購読済みだがイベント未着か条件不一致 | フィルタ・対象テーブルの設定を確認 |
| なし / StateCode=1 | 購読の登録に失敗している | 権限を確認して手③へ |
手③ 権限を補正し、購読を張り直す
購読レコードが存在しない場合、Application User のセキュリティロールを確認し、System Customizer または相当のプリビレッジを持つロールを追加する。
権限補正後、既存フローは自動的に再登録されない。以下の手順が必要だ。
- フローを「オフ」にする
- フローを「オン」にする（購読の再登録が走る）
- またはフローを編集して保存し直す
- テストイベントを発生させて実行履歴に起動記録が残ることを確認する
公式ドキュメントはワークアラウンドとして “modify trigger settings and save to force webhook re-registration” に言及している。テストイベントで一度通すまで完了と判断しない。
症状追跡 vs 実体確認
| 確認ポイント | 症状追跡アプローチ | 実体確認アプローチ |
|---|---|---|
| 最初に見る場所 | 実行履歴・エラーログ | 購読レコード（プラグインステップ） |
| 実行履歴が空の時 | ロジックの誤りを疑う | 購読が登録されているか確認 |
| 「◯日間未実行」警告の時 | 不発と判断する | 購読レコードの有無と合わせて読む |
| 機械 ID 運用の時 | 通常の接続確認のみ | 業務権限 + 購読登録権限の二層を確認 |
| 直し方 | ロジックを修正して保存 | 権限補正 → オフ→オン再登録 → テストイベント確認 |
個人テナントで手順を確認しておく場合
M365 Developer Program（無料）で構築した個人テナントなら、Application User の作成・セキュリティロール割り当て・購読レコードの確認まで、本番環境に影響なく一通り試せる。
→ 関連記事：[M365 Developer Tenant で作る個人 Power Platform 検証環境]（リンク予定）
この診断の射程と限界
購読レコードを確認しても当たりがつかないケースはある。購読が正常に登録されていても動かない場合（購読条件のフィルタ不一致・対象イベントがそもそも発火していない・登録の反映待ち）も起こりうる（いずれも公式ドキュメントの明示記述は未確認・実務観察ベース）。
権限を補填しすぎると監査リスクも生じる。Application User に過剰なロールを与えた場合の具体的なリスクは、関連記事 [access-that-outlives-the-app]（リンク予定）で扱っている。確認手順は 2026 年時点の PoC 環境での観察に基づいており、基盤バージョンや UI の変更で経路が変わる可能性がある。
まとめ
Dataverse イベントトリガーの不発は、ロジックよりも先に購読レコードの実在を確かめる。サービスプリンシパル構成では業務権限と購読登録権限の二層が独立しており、どちらが欠けても購読はエラー表示なしで未登録のまま残る。
次の一歩： フローがオンなのに一度も動いていなければ、まず Power Apps メーカーポータルでプラグインステップの一覧を開く。レコードが見つからなければ Application User のセキュリティロールに System Customizer（または相当ロール）があるかを確認する。権限補正後はオフ→オン再登録とテストイベント確認まで行う。
関連記事：
- [委任デプロイの承認自動化を設計する]（approval-is-a-signal-not-a-record・リンク予定）
- [機械 ID への権限付与：過剰リスクの境界]（access-that-outlives-the-app・リンク予定）
- [同じフロー、認証方式で変わる壊れ方]（same-flow-different-fragility・リンク予定）