0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

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

Posted at

はじめに

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

 そこで今回は無限トリガーを防ぐ方法を3つ紹介したいと思います

1.フィールドの値を基準としてフロー実行を制限する

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

トリガー条件の設定

画像
スクリーンショット 2025-05-18 204834.png

スクリーンショット 2025-05-18 215235.png

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

スクリーンショット 2025-05-18 215258.png

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

2.更新された列を基準としてフロー実行を終了させる

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

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

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

スクリーンショット 2025-04-28 235032.png
以降: 「アイテムが作成または変更されたとき」の「ウィンドウ開始のトークンのトリガー」を指定

実行すると更新があった列を取得を取得できます
スクリーンショット 2025-05-18 215500.png

条件アクション

上の例セクションと同じようにタイトル列を更新したい場合、
タイトル列が更新されている場合の分岐で、終了アクションを入れることで無限トリガーを防ぐことができます
スクリーンショット 2025-05-18 220530.png

スクリーンショット 2025-05-18 215901.png

3.フロー実行フラグをSPOに立てる

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

SPOでFlag用の列を作成する

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

スクリーンショット 2025-05-18 220938.png

Flag列の更新の有無により分岐する条件アクション

基本的な作り方はセクション「2.更新された列を基準としてフロー実行を終了させる」で解説した方法と同一です。
Flag列のTrue/Falseで分岐させるように作成しましょう
スクリーンショット 2025-05-18 223839.png

いいえの場合

「行の更新」アクションで、更新したい内容を設定します
この時Flag列にフラグを記入します
今回は「更新済」というテキストでフラグとしました
スクリーンショット 2025-05-18 224202.png

はいの場合ー条件アクション

ここからフラグの処理に関する内容になります
フラグの消去/未消去によって2回の実行に分けて処理をする必要があります
そのためフラグが立っているかどうかで分岐する条件アクションを追加します
スクリーンショット 2025-05-18 225722.png

はいの場合ー実行1回目でのSPOを更新を受けてトリガーされる実行向けのフラグを消す処理(実行2回目)

スクリーンショット 2025-05-18 225600.png
ここでは実行1回目の「行の更新」アクションで記入したフラグを消去する処理を行ったあとフローを終了させます

はいの場合ー実行2回目のフラグ消去を受けてトリガーされる実行向けのフロー終了処理(実行3回目)

実行2回目でフラグを消去すると、消去されたことをトリガーに再びフローが動きます
そこで正常系の実行1回目のアクションに処理がいかないように、それを検知して終了させるルートが必要となります
スクリーンショット 2025-05-18 230448.png
といっても、やることは終了アクションを追加するだけです

実行結果

実行1回目
スクリーンショット 2025-05-18 230951.png
SPOにレコード更新+フラグ記入がされます

実行2回目
スクリーンショット 2025-05-18 231117.png
フラグ消去が行われます

実行3回目
スクリーンショット 2025-05-18 231226.png
フラグ消去をトリガーとしたフロー実行の終了処理が行われます

計3回のフロー実行が必要ですが、無限トリガーは防ぐことができました
スクリーンショット 2025-05-18 231425.png

注意点

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

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

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

逐次処理はトリガーアクションの設定からコンカレンシー制御を1にすることで設定できます
スクリーンショット 2025-05-18 232948.png
コンカレンシー制御の設定を一度上限なしにしてしまうと、今後そのフローでは上限ありには戻せないので、慎重に検討することをお勧めします

さいごに

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

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?