Power Automateのflowが作成者では動くのに共有先ユーザーで失敗する場合、flowの実行権限と、各connectorが使うconnectionを分けて確認します。共有しただけで、全actionが作成者の認証を使うとも、呼び出した人の認証を使うとも限りません。connectorごとの設定と実際のresource権限を照合します。
この記事は、buttonや選択itemなど手動triggerを持つinstant cloud flowのrun-only共有を中心に扱います。desktop flowのrun-only roleや、全automated/scheduled flowを同じ仕組みとは考えません。共有・再認証・権限変更・flow起動は実施していません。比較表は架空例です。
目次
失敗したユーザーと起動経路を特定する
同じflow ID、environment、入口、入力条件で比較します。所有者がdesignerからテストしたrunと、利用者がSharePointやappから起動したrunは、呼出経路や渡る値が違う場合があります。共有URLが別copyや古いflowを指していないかも確認します。
表は横にスクロールできます
| 記録する項目 | 比較する理由 | 取り違えの例 |
|---|---|---|
| flow ID・environment | 同じ定義を比較 | 同名copyや別環境 |
| 手動triggerの入口 | run-only対象か確認 | scheduled flowと混同 |
| 利用者・所属group | 実行共有を確認 | URLを送っただけ |
| 失敗action・error | connectionとresourceを絞る | 最後のFailedだけを見る |
| 入力と対象ID | 所有者テストとの差を見る | 別site・recordで比較 |
run historyが見えない利用者に、履歴画面を何度も探してもらう必要はありません。Microsoftの共有権限ガイド（新しいタブで開く）では、run-onlyは定義編集やrun history閲覧の権限とは別です。利用者は起動時刻・入口・安全なerror要約を渡し、ownerが該当runを調べる役割に分けます。
実行だけ必要なら、co-ownerと混同しない
cloud flow共有の公式手順（新しいタブで開く）は、instant flowでrun-only userを指定し、ownerがconnectorのconnection方式を選ぶ流れを案内しています。flow detailsのRun only usersで、対象user/groupと設定を確認します。リンクを渡したことと、実行権限が付いていることを同一にしません。
co-ownerは設計・管理の権限を持つため、起動エラーの一般的な解決として追加しません。本人がどの入口から何を実行する必要があるかを確認し、必要な権限に絞ります。共有が許可される条件やlicenseは環境と機能で確認し、特定プランなら必ず全員使えると推測しません。
connectionの方式をactionごとに照合する
ownerはManage run-only permissions等で、各connectorが既存connectionを使うのか、Provided by run-only userなのかを確認します。一つのflowでも、すべてのconnectorが同じ方式とは限りません。
表は横にスクロールできます
| connection方式 | 実行前に確認すること | 成功を意味しないもの |
|---|---|---|
| 利用者が提供 | 利用者側の接続・認可・対象権限 | ownerの接続テスト成功 |
| flowで定義済み | 接続主体・共有条件・認証状態 | 利用者自身のresource権限 |
| 方式が未確認 | ownerが設定と対象actionを照合 | 全員を再認証させる |
利用者提供なら、その利用者が適切なaccountで接続し、対象site、list、mailbox、Dataverseなど必要なresourceへ操作できるかを見ます。固定connectionなら、そのidentityが対象を操作できるかを確認します。呼出userへresource権限を足すだけでは、固定connectionの権限不足は解消しません。
共有とresourceアクセス、policyを分ける
run-only userとして追加済みでも、connectorの認証やresourceへの必要権限が満たされるとは限りません。逆に、利用者がresourceを開けても、flowを起動する共有がなければ別の問題です。失敗actionと実connectionのidentityを対応させます。
401、403、connection未設定、DLPやlicenseに関するmessageは、同じ「権限不足」にまとめません。管理者へ確認する場合はenvironment、flow、connector、error、必要な操作を渡し、tokenや入力本文を送らないようにします。policyを回避するため別connectorへ移す処置にも進みません。
固定connectionを使うflowでは、呼出者が渡した任意のresource IDを高い権限で操作できてしまわないかも確認します。flowを共有することは、指定された業務機能を実行させる判断です。許される対象、入力検証、出力の見せ方を決め、作成者の権限を無制限に貸す入口にしないようにします。
所有者と利用者の差を、一条件ずつ比較する
同じ検証用recordと最小入力で、ownerと対象run-only userの経路を確認します。実データを使った送信や更新を何度も繰り返さず、可能なら読取や副作用を抑えた検証から始めます。認証account、connection方式、target、入力を一度にすべて変えると、何が原因だったか追えません。
表は横にスクロールできます
| 比較結果 | 次に見る場所 | 避ける修正 |
|---|---|---|
| 利用者のrunが作られない | 入口・flow共有・環境条件 | connectorだけ変更 |
| 認証が必要と表示 | 利用者提供connectionの状態 | ownerのsecretを配布 |
| runはあり特定actionが403 | 実identity・resource・policy | 全員をadmin化 |
| 別recordだけ失敗 | 入力・対象アクセス・業務条件 | flow全体の再作成 |
利用者が認可画面を完了できたことも、全actionの成功ではありません。必要なrouteと出力、実resourceの更新結果まで、owner側の履歴と利用者側の期待結果で照合します。
設定を戻せる形で再開する
変更前の共有範囲、connector別方式、connectionの管理者と対象resourceを記録します。変更で利用者の範囲やidentityが変わるなら、その運用判断を分けます。失敗したrunが途中まで外部更新していないかを調べ、同じ処理を最初から二重に実行しないようにします。
完了記録には、失敗した起動経路、原因を確認できた層、変更した最小設定、実際に試したuser/入力/結果、未確認のrouteを残します。共有設定を保存したことと、利用者が必要な業務を終えられたことを別に確認できれば、次の担当者も同じ手順で切り分けられます。