【Power Automate】SharePointリストの「フィルタークエリ」でハマって、コミュニティの皆様に助けて頂いた話。
2022年12月14日(水)、Microsoft Power Automate Advent Calendar 2022（カレンダー2）用
2日連続、アドベントカレンダー用に記事を書いております。
どうもyukioです。
私の勤め先では、Microsoft365が導入されており、SharePoint、Teamsなどは使える環境にあるので、Power Appsを使った簡単なアプリと、Power Automateを使った簡単なフローを構築しています。
今回はその開発をする中で、ちょっと扱いに困った現象と、それをコミュニティで相談して助けて頂いた話をご紹介します。
SharePointリストで「社員マスタ」を作った
Power Appsでアプリを開発して、夏から社内で運用しているんですが、毎日アプリを開いて入力してほしい業務だったので、Power Automateを使って、毎日「入力して下さーい」と、Teamsで通知するフローを作ろうと考えました。
アプリを使う人は全員ではないため、SharePoint Onlineのリストに「社員マスタ」を作り、「はい/いいえ」列で、通知を出す人と、出さない人を区別することにしました。
その「社員マスタ」。
はじめから、アプリを使用する人だけしか存在しないリストにしても良かったんですが、今後違うアプリを作ったときに汎用性がきくように、全社員を登録した社員マスタにしました。
※画像はイメージです。
Power Automateでフローを作るとき
上記のリストから「通知したい人」すなわち「Notice」列にチェックが入っている人に等しい人を取ってくるときには、SharePointコネクタの中にある「複数の項目の取得」アクションを使います。
「Notice」列が「true」の社員だけを抽出しようと思うと、普通「フィルタークエリ」はこのような形になるはずです。
「eq」は「equal」の略で「等しい」
「Notice」が「true」に「equal（等しい）」。
理論上はこれで正しいはずですよね。。。
そして、取ってきた人がひと目でわかるように、先ほどの「複数の項目の取得」の続きにこんなアクションを入れてみました。
さて、リストをもう1回見てみましょう。
「Notice」が「true」に等しいユーザーなので
・yukio
・阿井 上男
の4名が文字列変数に順番に追加されて行って、Teamsに通知されてくるはずです。
ところが、先ほどのフローを実行してみると・・・
なぜか、「Notice」列が「false」である
が取得されてしまいました。
逆じゃね！？
試したこと(1)とりあえず逆にしてみる
とりあえず、「フィルタークエリ」をこのようにしてみました。
真逆にしてみました。
「ne」は「not equal」の略なので
「Notice」列が「true」と「not equal（等しくない）」
これで実行してみると・・・
trueの社員が抽出されました。
逆じゃね！？
仕方ないのでこれで運用していたが・・・
「逆じゃね！？」と思いつつも、「Notice ne true」で意図する人を抽出することができるので、これで運用していました。
でも、どうにも気持ち悪いし、もし将来的にこの問題が修正されると、全く違う人に通知が言ってしまったりして怖いので、いつも参加させて頂いているコミュニティ「気ままに勉強会」で質問することにしました。
現象を見せてみたところ、何名もの参加者様から「こうしてみたら？」「ああしてみたら？」というアイディアが続々と！
その場で1個1個試していきました。
ここの参加者の方は、分からない問題に対してとことん検証してくれる人ばかりで非常にありがたいです。
以下に、あの場で試した内容を再度自分で試してみた結果を載せていきます。
※聞いたことの記憶、自分のメモ、当時のTeams会議チャットを基に書いています。「あのときこれ試したのに書かれてねえじゃん！」ってことがあるかもしれません。そこはご了承ください。
試したこと(2)シングルクォーテーションで囲む
フィルタークエリに文字列の列を使って、「この文字列に等しいとき」等に使うシングルクォーテーションを付けてみました。
こんな感じですね。
では実行結果を見てみましょう。
やっぱり逆。
シングルクォーテーションはそのままに、「eq」を「ne」にすると、意図するもの（trueの人）が抽出されました。
やっぱり逆。
試したこと(3)「true」の部分を式で入れてみる
「true」と直打ちするのではなく、「式」から「true」を入れてみました。
「複数の項目の取得」アクションはこのような見た目になります。
では実行してみます。
フローが失敗しました。
この書き方は正しい書き方ではないようです。
試したこと(4) (3)で入れた「true」の前後にシングルクォーテーション
次にご指摘いただいたのは、先ほどの「式で入れたtrue」の前後にシングルクォーテーションを入れるという方法です。
見づらいので拡大表示。こんな感じですね。
これで実行してみると・・・
やっぱり逆の結果になりました。
「eq」を「ne」に変えるとtrueの人が抽出されます。
うーん、やっぱり逆。
試したこと(5)１と入れてみる
次のご指摘が目から鱗でした。
「trueかfalse」ということは、2進数で言うと「1か0」、ということは↓↓↓
このようにしてみたら？というご指摘です。
試してみると・・・
おっ！trueの人が抽出された！
結論
SharePointリストでは「はい/いいえ」列をフィルタークエリに使わない運用方法にすべき！
例えば、
・数値列にして、通知してほしい人に「1」、そうじゃない人に「0」とするとか、
・選択肢列にしてみるとか
こんなところかなぁと思います。
・・・と、ここまででブログは締めようかなと思ったんですが、ふと
数値列と選択肢列、試してねえやん・・・
と思ったので、試してみて結果を続きに書くことにしました。
試したこと(番外編1)数値列
先ほどのリストに、数値列「Notice_Number」を作成し、
「通知したい人」に１、「通知したくない人」に０を入れました。
↓↓↓
そして、Power Automateの方の「フィルタークエリ」はこのように。
↓↓↓
では、実行してみます。
うん、ちゃんと、「Notice_Number」を「1」にした人のみが抽出されました。
試したこと(番外編2)選択肢列
今度は、選択肢列「Notice_Choice」を作り、「通知する」と「通知しない」の２つの選択肢を設けてみました。
↓↓↓
フィルタークエリはこのようにしました。
↓↓↓
実行結果はこちら
こちらもきちんと「通知する」にした人が抽出されました。
さいごに
今回は、Power AutomateでSharePointリストのデータを扱うにあたり、ちょっと困った現象をお話ししました。
今後ともコミュニティで勉強した内容や、助けて頂いた事や、自分で試したことをブログにまとめていきたいと思います。
(2023/02/12追記)番外編の番外編「falseを基準にする」
2023年1月、takmasさんがQiitaにて、このテーマに関する記事を投稿されていました。
その中に、本ブログでは試してない内容がありました。
本ブログ冒頭、そして(1)では「trueを基準」に考えてフィルタークエリを書いていましたが、それを「falseを基準」にするというものです。
試したこと(番外編の番外編1)「ne false」
trueの人を抽出したいので、フィルタークエリはこのような形になります。
「ne false」なので「falseでない」
つまり「true」
つまり「チェックがついている人」
が抽出されてくるはずです。
フローを走らせてみます。
ちゃんと「trueの人」が抽出されました！
試したこと(番外編の番外編2)じゃあ「eq false」ではどうなるか？
じゃあ、その逆だとどうなるか試します。
さっきの逆ですね。
理論上は「falseの人」が抽出されてくるはずです。
ではフローを走らせます。
ちゃんとfalseの人が抽出されましたね。
他の方が紹介されていた内容でも「ああ、そうなのね」だけじゃなく、自分で試してアウトプットすることで、定着につながったような気がします。
