Power Automateのトリガーの値は、そのまま参照しないほうが後々困らない

Power Automateでは前段までのアクションの値を後続のアクションで使用することで、他のデータソースに値を登録したり、条件によってアクションを変更するなど、決められた手続きで自動化するサービスです。
一度自動化してしまえばあとは安心！ということにはならず、業務要件が変動するにつれて、トリガーの見直しが必要になってくることがあります。

どんな時に見直す？

例えば、SharePointトリガーの「アイテムが作成または変更されたとき」を例に挙げます。読んだままのごとく、データの新規作成および更新時に自動的に動作するトリガーですが、更新時の実行が不要になったり、規模が広がりPower Appsアプリ化する必要が生じた場合、このトリガーでは要件を満たせないことが見えてきます。

そういったときにトリガーを削除、新しいトリガーを割り当てることになるのですが、Power Automateはトリガーの削除時に、triggerOutPuts()を使用するコンテンツをすべて削除してしまいます。

何が起こる？

コンテンツが削除されると、当然後続のアクションに再設定する必要がありますが、一度作成したアプリやフローからしばらく離れていると、どのような設定を行っていたか、どのような背景でこのロジックにしていたのか、といったことを忘れがちになっています。そのような状態で再設定するにも記憶を呼び起こしたり、どのような関数を使用していたか再検証したりするなど、修正に余計な時間をかけてしまうことになります。

Power Automateは処理が多岐にわたるほど、テストやデバックに余計な時間がかかってしまいますし、どんなに経験者でも意図した動作になるまで、エラーをつぶしきってテストをすることから避けられません。

どのようにすればよい？

こういったことを避けるためには、作り直しが発生しないように最初から設計することをおススメします。少し言い換えると作成時のルールを自分で決めてしまうということです。

私がおススメするルールは「トリガーの次のアクションで値を取得する」です。

例として、上記の「アイテムが作成または変更されたとき」では、次に「項目の取得」アクションを作成し、トリガーのIDで値を取得します。後続のアクションではトリガーの値ではなく、「項目の取得」アクションの値を使用することで、トリガーの変更があった際には、「項目の取得」のIDに対して、新しく設定したトリガーのIDを設定するだけでよくなり、余計なトラブルを発生させないようにできます。

これはPower Appsからクラウドフローを起動する際も同様です。Power Appsからギャラリーやフォームのパラメタをクラウドフローに渡すのではなく、何等かをSubmitした後にクラウドフローを起動し、上記と同様に「項目の取得」のIDには、Power AppsのLastSubmit.IDなどを設定します。これにより。手戻り少なく開発することができます。
もちろん、Power Appsの場合はアプリの仕様は自身で決めることになるのでケースバイケースですが、開発環境の特性を理解して開発を進めることも、コーディング同様に開発生産性を高めるための有効な手段だと考えます。

〆

こういったTipsは「Power Apps・Power Automateで〇〇作れます！」といったコンテンツより地味なため、情報として拡散されづらい分、表立って発信する人は多くありません。しかし、アプリやフローを開発するすべてのユーザーに共通の生産性向上Tipsですので、ぜひ取り入れた上で、手戻りの少ない開発スキルを手に入れてください。