概要
偶然、トリガーであるはずの項目を、アクションとして追加できることに気が付きました！
有識者に伺ったところ、以前からできていたとのことでしたが、僕自身は今の今まで全く気付いていませんでした。
「トリガーなんだからアクションに使えるはずない！」 という思い込みですね…
ということで、今回はこれを使って面白いフローが使えないか考えてみた、という内容です！
注意
推奨される使い方ではありません。
「こんなこともできるのか」という参考程度（面白半分）でとらえてください。
ちゃんと使えるの？
まずはとりあえず動作確認です。
トリガーの種類にはいくつか種類あるようですので、それぞれ確認してみましょう。
正式な分類ではありませんが、今回は以下の分類で動作を確認しました。
- インスタントフロー（プッシュトリガー）
- 自動化フロー（ポーリングトリガー）
- 自動化フロー（Webhook≒プッシュトリガー）
参考にさせていただいた記事
たなの覚え書き｜Power Automateのトリガー種別と注意事項について
インスタントフロー（プッシュトリガー）
ボタンを押したとき、など任意のタイミングで実行するトリガーです。
ここでは、フローの作成画面から「インスタント クラウド フロー」として選択できるトリガーを指します。
試しにこんなフローを作成してみました。
検証用のフローを実行してみると、エラーとなりました。
エラーの詳細
Invalid version: hybridtriggers
他にも、エラーは起こらないものの応答の出力に何も情報がなく、実質使えないトリガーがあったり...
そもそもアクションとして追加できないトリガーがあったりしました。
全てを確認したわけではありませんが、インスタントトリガーはアクションとして使用することはできないようです。
自動化フロー（ポーリングトリガー）
ここでは、「自動化したクラウド フロー」のうち、ポーリングトリガーのものを指します。
ポーリングトリガーは一定間隔で定期的に応答を確認するトリガーです。
試しにこんなフローを作成してみました。
このトリガーは、普通にトリガーとして追加し、コードのプレビューで確認すると、5分間隔で実行されることがわかります。ポーリングトリガーである証拠ですね。
確認用のフローを実行してみると、すぐに(アクションとして追加した)トリガーは実行されず、しばらく応答を待機していることがわかります。
この状態で、トリガーされる条件、リストへのアイテム追加を行いました。
更新間隔の5分以上待ってみましたが、どうやら通知を受け取ることはできないようです。
…と思っていたら、5分を大きく超えた6時間後に実行されました。
「フロー保存後の初回は時間がかかるのかも？」と思い何度か実行してみましたが、同じ結果でした。
ということで、ポーリングトリガーもアクションで応答を待ち構えることは実質的にできないようです。
自動化フロー（Webhook≒プッシュトリガー）
ここでは、「自動化したクラウド フロー」のうち、ポーリングトリガーでないのものを指します。
Webhookトリガーはアプリ側から通知が送信されることで、ポーリングトリガーとは違って即時的に実行されるトリガーです。
トリガーの機能としてはインスタントトリガーと同じ分類ですが、アプリからの更新を受け取る自動化したクラウドフローということで、ユーザーからするとわかりづらい分類になっているかもしれません。
試しにこんなフローを作成してみました。
このトリガーは、普通にトリガーとして追加し、コードのプレビューで確認しても、更新間隔の設定がありませんので、ポーリングトリガーとは異なることがわかります。
実行すると、待機状態となりました。少なくともエラーにはなってないですね。
トリガーとなるフォームの送信をしてみると
即座に応答を受信しました。こちらは動作として支障がなさそうです。
ということで、トリガーをアクションとして使用できるのは自動化フロー（Webhook≒プッシュトリガー）のものだけということになりました。
利用例
これを利用するフローを考えてみました。
特定のユーザーにFormsの回答を依頼するメッセージを送付し、そのユーザーからの回答を受け取るまで１日置きにフォローメッセージを送付するフローです。
長いのでフローの全体像を折りたたんでおきます。
サンプルフロー
ついでにZIPファイルも置いておきます。
github｜アンケート回答の督促_20231203142658.zip
使用する際の注意点
一般的な使い方を逸脱したフローですので、いくつか注意点があります。
トリガー独自の設定はできない
トリガーには条件を指定して、無駄なフローの発火を抑えられる設定があります。
同じトリガーでも、アクションとして追加した場合は、このようなトリガー独自の設定が使用できません。（普通のアクションと同じ設定のみ）
分割されない
同じく、トリガーとしての設定に「分割」というものがあり、クラシックデザイナーの場合はこのオプションが既定でオンになっています。
アクションとして実行する場合は、この設定が使用できないため、Apply to eachなどの配列処理が必要になります。
狙った応答をトリガーできない
普通、応答を待機する系のアクションは、送った要求に対する決まった応答を受け取るため、他のユーザーからの応答を間違って取得するようなことはありません。
しかし、トリガーをアクションとして使う場合、どの応答があってもトリガーが発火してしまうため、特定の応答を受け取るといったことができません。
また、トリガーの条件を設定することもできないので、事前に条件を指定して発火を絞り込むということもできません。
そのため、トリガーされた後に、目的の応答かどうかを確認する条件分岐などの処理が必要になります。
さらに、狙った応答でなくともアクションとしては終了してしまいます。
そのため、狙った応答を受け取りたい場合は、目的の応答を受け取るまで何度もトリガーさせる、Do Loop などの繰り返し処理が必要になります。
要求数の消費
- 目的の応答を取り出すまで行うDo Loop
- 応答が配列のため必要になるApply to each
- 応答の詳細を確認する条件分岐
1人のユーザーからの応答を受け取るためにこれだけの入れ後構造が必要になります。
これだけ繰り返されるということは、もちろんその分APIの実行回数もかさんでしまいます。
１人のユーザーからの応答を受け取るだけでもこれだけに無駄が多いということは、複数のユーザーからの応答を受け取るためには…。
(況や～をや)
まとめ
ということで、トリガーをアクションとしてして使う方法でした。
単純に応答を待機する系のアクションが増えたと考えると、フローの幅が広がったように感じましたが、今回言及した制約やデメリットを考えると、基本的には推奨できない使い方であると総括します。
変わった使い方は面白いですが、本来の用途を外れるとそれだけ良くない面が多くなりますね。
用法容量を守った、よいローコードライフを！