SharePointの親フォルダーではPower Automateが起動するのに、サブフォルダーではrunが作られない場合、最初にトリガーの正式名を確認します。旧式の「in a folder」トリガーには、サブフォルダーの追加・更新で起動しないと公式に説明されたものがあります。接続を作り直す前に、その制約に当たるかを確認します。
対象はSharePoint connectorを使うcloud flowです。本稿ではトリガーの変更、ファイル作成、接続・権限変更、flow実行はしていません。以下のフォルダー構成と確認表は架空例で、特定環境の再現結果ではありません。
目次
正式名とoperation IDを記録する
MicrosoftのSharePoint connector reference（新しいタブで開く）で、使用中のトリガーを確認します。「file」「item」「properties only」「in a folder」を省略せずに控えます。似た表示名でも、監視するeventや出力が違います。
表は横にスクロールできます
| トリガー | 確認する点 | 判断を混ぜないこと |
|---|---|---|
| When a file is created in a folder (deprecated) | 旧式、サブフォルダーの制約 | library全体の監視と同一視 |
| When a file is created or modified in a folder (deprecated) | 旧式、作成と変更の対象 | 再帰監視を期待 |
| When a file is created (properties only) | library・Folder設定、作成event | ファイル本文も届くと仮定 |
| When a file is created or modified (properties only) | library・Folder設定、変更event | 自己更新の再起動を見落とす |
公式referenceは、上のdeprecatedな二種類について、サブフォルダーへ追加・更新されたファイルでは起動しないと説明しています。親で成功し子で失敗する条件が一致するなら、認証障害と断定せず、この監視範囲の違いを原因候補にします。
site・library・階層を実際のpathで照合する
たとえば「共有ドキュメント/受付」を見ていて、「共有ドキュメント/受付/部門A」への追加だけを試したなら、親直下と子の二条件を分けます。ブラウザーの表示名と、connectorが参照するsite・library・folderの値を照合します。移動先や同名libraryを取り違えていないかも確認します。
表は横にスクロールできます
| 架空の入力 | 検証したいこと | 残す記録 |
|---|---|---|
| 受付直下で新規作成 | 直接の監視対象か | ファイル識別子・作成時刻 |
| 部門Aで新規作成 | 子階層が対象か | 階層とrun有無 |
| 部門Aの既存ファイル変更 | 作成と変更の違い | event種類・変更時刻 |
| 別部門で作成 | 対象外の除外 | 起動・除外の意図 |
既存ファイルの移動を、新規作成と同じeventだと決めつけないようにします。確認した操作、時刻、ファイルの識別子を残し、単に「アップロードした」とだけ記録しません。connectorの確認間隔も踏まえ、短時間に同じ入力を繰り返して不要な処理を増やさないようにします。
library型のトリガーへ変える場合は、対象と出力を設計する
現行のproperties only型にはlibraryとFolderの設定があり、公式referenceではFolderを空欄にするとlibrary全体を対象にできると案内しています。旧式と同じ制約だと推測せず、利用するoperationと実際の階層条件で検証します。特定Folderを指定した場合の期待する再帰範囲も、未実測のまま全階層対応と断定しません。
library全体を監視して対象pathを条件で絞る設計なら、対象外のファイルを後続で更新・通知しないようにします。架空の「受付」と「受付旧」が混ざるような曖昧なprefixだけで判定せず、実イベントのpath形式と区切りを確認して条件を作ります。内部名、URLエンコード、欠損値も検証対象にします。
properties only型はファイルのプロパティを返すため、本文binaryが必要なら別途Get file content等を設計し、返された識別子を対応させます。旧トリガーの出力を前提にしたactionを、そのまま使えると考えません。移行前後の出力fieldと、参照している後続actionを表にします。
監視範囲以外の未起動も分ける
新旧どちらのトリガーでも、Trigger conditionsがイベントを除外していないか、flowが有効か、接続主体が対象site/libraryへアクセスできるかを確認します。条件未達と接続エラーを、サブフォルダー制約の一語で片付けないようにします。
runが作られているなら、起動しない問題から、失敗actionや参照fieldの診断へ進みます。ファイル取得が失敗したrunを「trigger未起動」と記録すると、直す場所が変わってしまいます。親と子で同じidentity・条件を比較したかも確認します。
切替では重複処理と取りこぼしを確認する
検証環境で、親直下、子階層、対象外、作成、変更を分けて期待結果を確かめます。flow自身がファイルのpropertyを更新するなら、変更triggerが再び起動する条件も見ます。run数が増えたことだけで成功にせず、対象ファイルが必要な回数だけ処理されたかを確認します。
旧flowと新flowを同時に有効にすると、同じファイルへ二重に通知・登録する可能性があります。切替時刻、処理済みのfile/version、未処理入力、外部更新の対応を記録します。停止していた間のeventが必ず再配信されるとは仮定せず、必要な再照合を別に設計します。
変更前のトリガー設定と後続参照を保存し、失敗時は差分を戻せるようにします。設定を戻しても送信済み通知や作成済みrecordは戻らないため、外部状態を読んでから再処理範囲を決めます。完了記録には、採用した正式トリガー、対象階層、作成・変更別の結果、対象外条件、未確認のpathを残します。