Automateで無限トリガーを回避する方法3選

## はじめに
	
　SPOの更新をトリガーとして動くフローの処理で、トリガーと同一のSPOに更新する処理がある場合は未対策では無限にフローが実行されてしまいます

　そこで今回は無限トリガーを防ぐ方法を3つ紹介したいと思います
	
	
## １.フィールドの値を基準としてフロー実行を制限する

ベーシックな方法です
トリガーアクションにトリガー条件を設定することにより、更新されたレコードのフィールドが特定の値の場合にのみフローが実行されるようにします

#### トリガー条件の設定

画像
![スクリーンショット 2025-05-18 204834.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3713277/9e7d6295-e377-41b3-8d3b-1a3b4efb112e.png)

![スクリーンショット 2025-05-18 215235.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3713277/8cba6a31-2f7d-445e-a5a2-5974af93efee.png)


アクション設定内のトリガーの条件のテキストボックス内で設定することができます
PowerFx形式で入力するので、orやandをなどの論理式を組み合わせることで多少複雑な条件も設定可能です

![スクリーンショット 2025-05-18 215258.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3713277/f5aa7377-fc8c-4cba-943e-548ff9764cca.png)

上の例はタイトル列を固定値で更新し、更新後はトリガー条件でフロー実行を制限させています


## 2.更新された列を基準としてフロー実行を終了させる
「アイテムやファイルの変更を取得する (プロパティのみ)」を使用して、
どの列が更新されたかを確認し、それによって処理を実行するか否かを判断する仕組みです

この方法ではトリガー条件のように「フロー実行をさせない」ということはできないので、実行履歴に残ってしまうことが難点です。

#### アイテムやファイルの変更を取得する (プロパティのみ)

![スクリーンショット 2025-04-28 235032.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3713277/c4846c56-7491-49e2-8e33-00d1dca886e8.png)
以降: 「アイテムが作成または変更されたとき」の「ウィンドウ開始のトークンのトリガー」を指定

実行すると更新があった列を取得を取得できます
![スクリーンショット 2025-05-18 215500.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3713277/1a6c35f6-d0b5-47b3-84f0-57b462836fc4.png)


#### 条件アクション
上の例セクションと同じようにタイトル列を更新したい場合、
タイトル列が更新されている場合の分岐で、終了アクションを入れることで無限トリガーを防ぐことができます
![スクリーンショット 2025-05-18 220530.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3713277/e35a185d-4ad2-46da-86bd-f348f918c22e.png)

![スクリーンショット 2025-05-18 215901.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3713277/8caec545-cce6-4603-8860-a15da023566d.png)


## 3.フロー実行フラグをSPOに立てる
少々強引な方法になりますが、上の2つの方法で無限トリガーを防止できない場合に使用します。
本来であれば、この方法をとる前にテーブル設計を変更したほうが望ましいです。

#### SPOでFlag用の列を作成する
トリガー元のリストにFlag列作成を作成します
個人的にBoolean型は使いにくいので1行テキストにしています

![スクリーンショット 2025-05-18 220938.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3713277/c571a053-c9d6-4d04-a025-97978ce2fcb2.png)

#### Flag列の更新の有無により分岐する条件アクション
基本的な作り方はセクション「2.更新された列を基準としてフロー実行を終了させる」で解説した方法と同一です。
Flag列のTrue/Falseで分岐させるように作成しましょう
![スクリーンショット 2025-05-18 223839.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3713277/83abda7b-5d21-4928-9ce8-d34eb24cf665.png)

#### いいえの場合
「行の更新」アクションで、更新したい内容を設定します
この時Flag列にフラグを記入します
今回は「更新済」というテキストでフラグとしました
![スクリーンショット 2025-05-18 224202.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3713277/43902352-8078-43d2-b219-d982b8b487a6.png)

#### はいの場合ー条件アクション
ここからフラグの処理に関する内容になります
フラグの消去/未消去によって2回の実行に分けて処理をする必要があります
そのためフラグが立っているかどうかで分岐する条件アクションを追加します
![スクリーンショット 2025-05-18 225722.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3713277/ba15494a-47ac-4f13-917c-70cdc2ce7eb4.png)


#### はいの場合ー実行1回目でのSPOを更新を受けてトリガーされる実行向けのフラグを消す処理(実行2回目)
![スクリーンショット 2025-05-18 225600.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3713277/039ad5ce-0d13-4596-b332-47db176ec19d.png)
ここでは実行1回目の「行の更新」アクションで記入したフラグを消去する処理を行ったあとフローを終了させます

#### はいの場合ー実行2回目のフラグ消去を受けてトリガーされる実行向けのフロー終了処理(実行3回目)
実行2回目でフラグを消去すると、消去されたことをトリガーに再びフローが動きます
そこで正常系の実行1回目のアクションに処理がいかないように、それを検知して終了させるルートが必要となります
![スクリーンショット 2025-05-18 230448.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3713277/ea3c9392-7c2c-4503-ac46-d90c8ba9987c.png)
といっても、やることは終了アクションを追加するだけです

#### 実行結果
**実行1回目**
![スクリーンショット 2025-05-18 230951.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3713277/f40fecda-437c-45ff-b10e-0c08795e29d7.png)
SPOにレコード更新＋フラグ記入がされます

**実行2回目**
![スクリーンショット 2025-05-18 231117.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3713277/04639af6-8630-474d-89c8-2e9d69451eb5.png)
フラグ消去が行われます

**実行3回目**
![スクリーンショット 2025-05-18 231226.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3713277/7688fdae-66bf-414e-80f3-6bcddf5b5bf3.png)
フラグ消去をトリガーとしたフロー実行の終了処理が行われます

計3回のフロー実行が必要ですが、無限トリガーは防ぐことができました
![スクリーンショット 2025-05-18 231425.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3713277/0ecb5876-4820-4d21-8d2d-6034d49a8ff4.png)

#### 注意点
この方法の欠点はフラグ処理のためにフロー実行が3回に渡ってしまうことです。
SharePointトリガーは、ポーリングトリガーなので実行の間隔にはラグが発生します。

ポーリングトリガー・・・定期的にトリガー元のリストを見に行き、実行条件が満たされていれば実行されるタイプのトリガー

通常は5分間隔でトリガーされますが(Premiumライセンスでは1分)5分間の間に複数回条件を満たした場合、ポーリングしたタイミングで一気に複数の実行が行われます
実行の速度、順序によっては不整合が発生する可能性があるので、短時間で何度もトリガーされるようなタイプのリストには向きません
またフローの実行は逐次処理にしたほうが、個々の実行速度に左右されず無難です(実行速度がとんでもなく遅くなりますが)

逐次処理はトリガーアクションの設定からコンカレンシー制御を１にすることで設定できます
![スクリーンショット 2025-05-18 232948.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3713277/e2a6fa1b-a94a-4377-af80-d08c5cc1e215.png)
コンカレンシー制御の設定を一度上限なしにしてしまうと、今後そのフローでは上限ありには戻せないので、慎重に検討することをお勧めします

## さいごに
無限トリガーを回避する方法3選いかがでしたでしょうか
3つ目の方法はあまりお勧めできないですし、まだまだ改善の余地があると思っているので、なにか良い案があればコメントいただけたら嬉しいです