Logic Apps/Power Automate に限らずですが、条件分岐の入れ子を作り上げてしまうことが、ローコードだと結構あるかなと思います。ビジュアル的に作れるので、直観に従って、『ここがYesなら、つぎにこれを判定して、さらにこれを・・・』という具合です。
例えば以下のようなケースを考えます。
タスク一覧のようなものを対象にして、それぞれの優先度、期日、ステータスに応じて何らかの処理をそれぞれ行いたいような場合です。
ナイーブにはこれを作りこむと次のようなフローになります。
激しく条件分岐が入れ子になっています。そして自分でもこれで完全かどうか自身がないです。。
さて、そもそも条件分岐を入れ子にすると何がよくないかというと、
- フロー全体が見にくい = 間違えやすい
- 結果の理解をするために毎回条件分岐を全部開かないといけない
- パターンの網羅がわかりづらい
などなど、さまざまに弊害はあります。高々3個のプロパティで条件分岐させているだけでもこのくらいの複雑さになるので、これが増えればもっと入れ子の深さは深くなり、複雑さも増します。
なお、Power Automate/Logic Apps では 入れ子の深さは8が限界です。これより深い階層のアクションを作ろうとするとエラーになります。
今回はこのようなフローの解消方法の1つを紹介します。
1. そもそも処理しないものはフィルターする
今回の例では、『タスクが完了のもの』は処理していません。このようなデータをふるいにかけるためだけに条件分岐を使うとそれだけで複雑さが＋１されるので、ふるいはふるいで対応します。
Dataverse (for Teams) のようにFilter Queryに対応するデータソースまたは対応した列の場合には、素直にFilter Queryを指定しましょう。
もしくは、Filter Queryに対応していないデータソースや、列の場合でも、『アレイのフィルター処理』をデータ取得直後に入れることで、後続処理で無駄なレコードを相手にしなくて済みます。
2. 変数を使って最後はフラットなスイッチ
いきなり表からフローを作り始めると先ほどのような入れ子地獄に陥るので、まずは樹形図で取りうるパターンとその処理を書き出してみましょう。
簡単のために期限とステータスだけに注目すると以下のような樹形図がかけます (ここでは1のフィルターを施した前提)
樹形図のそれぞれの列はお互いに独立しているので、フローとしてもアクションを独立にできます。
『変数を使って』というのはまさに、この樹形図のどこを通ったか を示す変数です。
イメージ図は以下のような形です。各判定で最初に初期化しておいた文字列変数に、どういうパターンだったかを記録していき、最後に出来上がった文字列に応じた処理を施します。
このとき、各列 (判断) は互いに独立なので、入れ子ではなく縦に並べることができます。結局フローとしては入れ子が解消されて多少見通しのよい恰好になります。
もともとアナログに樹形図からスタートしているので、処理もちゃんと網羅できているかが見やすいです。 当然、入れ子にもなっていないので、各分岐の結果は (結果の文字列だけでもいいですが) 一個ずつ、分岐を開いていけばわかります。
おわり
ローコードでも作っていくときにアナログな『設計書みたいなもの』はあったほうがいいかなと個人的には思います。
ここで見たような入れ子の抑制もそうですが、考慮していないパターンの発生を抑えるうえでもデータの発生パターンを網羅できるような記法で書いてみたり、状態の遷移を整理してみたり。
もちろんフローを作るテクニックもあったほうがいいですが、それとは別にこういう考えかたもありますよという参考になれば幸いです。
